incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ronald higgins <ronald.higg...@gmail.com>
Subject Re: [AFSCS40] Release status for CS 4.0
Date Thu, 01 Nov 2012 08:41:17 GMT
Heh Guys,

Any news on when V4 release is landing? Or did I miss an announcement.

Regards

Ronald

On Tue, Oct 2, 2012 at 10:50 PM, Noah Slater <nslater@tumbolia.org> wrote:
> Cool, thanks Chip.
>
> As a follow up, Apache httpd do "pre-release" versions for testing on the
> dev@ list.
>
> "This directory contains pre-release test versions of the Apache HTTP
> Server and are not officially released tarballs. Please use only for
> testing."
>
> http://httpd.apache.org/dev/dist/
>
> I am not involved with the httpd project, but I am guessing they use this
> as a staging area for builds that people want the community to test, and
> for hosting artefacts that are being voted on. (For a point of reference,
> in CouchDB Landâ„¢ we call an RFC on the proposed release to catch any
> concerns before the length release and voting process.)
>
> On Mon, Oct 1, 2012 at 4:29 PM, Chip Childers <chip.childers@sungard.com>wrote:
>
>> On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <nslater@tumbolia.org> wrote:
>> > Minor correction, "build" is official ASF nomenclature.
>> >
>> > "A Build is a package which is not suitable for distribution to the
>> general
>> > public. They are works-in-progress, and as such the only people builds
>> > should be offered to are other people working on product development at
>> the
>> > foundation."
>> >
>> > "Release candidate" is not, however, and is best avoided. We don't really
>> > do release candidates at apache, so if you use it to talk about voting
>> > artefacts, you risk confusing people who assume you're using the more
>> > common sense of the word. If something is alpha, call it alpha.
>>
>> I like the distinction you made here, specifically that we stop using
>> the term release candidate until we are talking about something that
>> we will / are voting on.  To me, a release "candidate" is exactly
>> that:  a candidate being voted on.
>>
>> Let's start using those terms from now on.  The weekly builds that
>> I've been doing (source only) are just that - builds.
>>
>> -chip
>>
>> > On Sun, Sep 30, 2012 at 12:23 PM, Noah Slater <nslater@tumbolia.org>
>> wrote:
>> >
>> >> Chip,
>> >>
>> >> Can you point me to where you're hosting these builds?
>> >>
>> >> We need to be super careful about the distinction between the following
>> >> items:
>> >>
>> >>    - A build
>> >>       - A source or binary package that will note be voted on
>> >>    - A release candidate
>> >>       - A source package that is being voted on
>> >>    - A release
>> >>       - A source package that has been voted on
>> >>
>> >> (Please note that "build" and "release candidate" are not official ASF
>> >> nomenclature. You could call a build a "package" or a "nightly" or a
>> >> "tarball" or whatever it happens to be. Build kinda works for most
>> things.
>> >> It's a preparation of the source. And release candidate might just be
>> >> called "the voting artefact" or what have you. It's the thing we're
>> voting
>> >> on for a release.)
>> >>
>> >> A binary package will never be anything more than a build that is
>> prepared
>> >> by an individual for the convenience of others. So let's just get that
>> out
>> >> of the way. A binary package can never graduate to anything other than a
>> >> build.
>> >>
>> >> A source package can do many things though.
>> >>
>> >> On the one hand, as an individual, we can prepare source packages as
>> >> snapshots, or nightlies. A committer can upload them to
>> people.apache.org,
>> >> and advertise them to developers. (But we must not advertise them to
>> users
>> >> without heavy caveating.) Generally, these are used by people working on
>> >> the project itself, not with the project. Though, we may want to
>> highlight
>> >> a particular build before starting the official release process, to get
>> >> feedback on things.
>> >>
>> >> If we think we're ready for a release, we can prepare a build to vote
>> on.
>> >> We upload this to people.apache.org, and we start a VOTE thread. At
>> this
>> >> point, the build becomes a release candidate. And only at this point.
>> (Also
>> >> note that because a release candidate must progress to a release without
>> >> any modification, we cannot include "RC" in the version number.)
>> >>
>> >> If the vote passes, the source package becomes a release, and we upload
>> it
>> >> to our dist dir and tell users about it.
>> >>
>> >> In this context, language like this concerns me:
>> >>
>> >> "each RC build should come with release notes"
>> >>
>> >> These are not release candidates unless we're voting on them, and they
>> >> certainly must not come with release notes.
>> >>
>> >> If an individual is providing nightlies, let's call them nighties, and
>> >> let's attach "QA notes".
>> >>
>> >>
>> >> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <
>> chip.childers@sungard.com>wrote:
>> >>
>> >>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Alex.Huang@citrix.com>
>> >>> wrote:
>> >>> > Chip,
>> >>> >
>> >>> > In the future, we should.  If we were doing this right (which we
>> aren't
>> >>> today), each RC build should come with release notes about what QA has
>> >>> found to be problems.  I think what you're putting up right now are
>> more
>> >>> closer to nightly unstable builds than RC builds.
>> >>>
>> >>> Agreed on that front.  Really though, I'm not doing a "build".  I'm
>> >>> packaging the code only.
>> >>>
>> >>> We're in a weird state right now, since we won't be able to pass a
>> >>> vote yet.  The way I see other projects doing this, is that even
>> >>> unstable builds / source packages can be considered a release.  They
>> >>> just get labeled something like "alpha" or whatever.  The projects do
>> >>> vote on them though (which we're not ready for).
>> >>>
>> >>> I guess I'll just keep incrementing for now - so that those people
>> >>> looking at the source package know that it's a new version (vs. Citrix
>> >>> QA, which I believe is pulling unofficial builds from Jenkins for
>> >>> functional testing).
>> >>>
>> >>> -chip
>> >>>
>> >>> > The good news is that the quality has been pretty good so even
the
>> >>> nightly unstable builds are good.  Today, that's mostly due to the
>> majority
>> >>> features in this release came from Citrix and were already tested by
>> >>> Citrix.  For future releases, we should follow a process of QA
>> completes
>> >>> 100% testing and that's a RC build while there's nightly builds for
>> people
>> >>> who are actually developing if they're interested.
>> >>> >
>> >>> > --Alex
>> >>> >
>> >>> >> -----Original Message-----
>> >>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
>> >>> >> Sent: Monday, September 24, 2012 8:14 PM
>> >>> >> To: <cloudstack-users@incubator.apache.org>
>> >>> >> Cc: cloudstack-dev@incubator.apache.org
>> >>> >> Subject: Re: [AFSCS40] Release status for CS 4.0
>> >>> >>
>> >>> >> Alex,
>> >>> >>
>> >>> >> I've been cutting "RC" source code bundles, and have been numbering
>> >>> them
>> >>> >> as RCx (Wednesday will be RC3).
>> >>> >>
>> >>> >> Do you think I should switch to a more informal scheme until
we have
>> >>> >> something to vote on officially?
>> >>> >>
>> >>> >> - chip
>> >>> >>
>> >>> >> Sent from my iPhone.
>> >>> >>
>> >>> >> On Sep 24, 2012, at 10:27 PM, Alex Huang <Alex.Huang@citrix.com>
>> >>> wrote:
>> >>> >>
>> >>> >> > Hi All,
>> >>> >> >
>> >>> >> > I've been reminded that I've neglected to update the community
on
>> the
>> >>> >> current status for CloudStack 4.0.  I apologize for that oversight.
>> >>>  From now til
>> >>> >> the actual release, I will give a daily update on the status.
 If
>> you
>> >>> feel anything
>> >>> >> is missing, please let me know and I'll try to include them
on the
>> >>> next update.
>> >>> >> >
>> >>> >> > Summary
>> >>> >> > As of 9/24/2012, CloudStack 4.0 release has past code
freeze stage
>> >>> (over
>> >>> >> three weeks ago).  A source code branch has been forked and
is
>> called
>> >>> 4.0.
>> >>> >> Nightly build is running on Jenkins on the 4.0 build.
>> >>> >> >
>> >>> >> > Feature List
>> >>> >> > There are two features that missed the 4.0 release.  Auto-Scaling
>> and
>> >>> >> Brocade Plugin.  Both are due to having significant code changes
due
>> >>> past the
>> >>> >> code freeze date.
>> >>> >> >
>> >>> >> > Code Readiness
>> >>> >> > - There are ~5 code related reviews on the review board
scheduled
>> >>> for 4.0.
>> >>> >> Most of them are waiting for review and commit.
>> >>> >> > - There are <10 bugs on Jira for the first cut of the
release.
>> >>> >> > - Upgrade from previous versions is currently being worked
on.
>> >>>  Scheduled
>> >>> >> to be done by the end of the week.
>> >>> >> >
>> >>> >> > License Readiness
>> >>> >> > - Majority of the VM configuration issues have been resolved.
>>  There
>> >>> is one
>> >>> >> remaining wrt rsyslog.conf.  Thanks to Chiradeep and Chip.
>> >>> >> > - Technology export issues are still be worked on by David
Nalley
>> >>> and AFS
>> >>> >> legal.  This may be a blocking issue.
>> >>> >> > - Licenses need auditing.
>> >>> >> >
>> >>> >> > Doc Readiness
>> >>> >> > The current plan for docs is to write an INSTALL.TXT to
give
>> >>> instructions on
>> >>> >> how to install from source.  All docs will be generated to
a living
>> >>> document
>> >>> >> that continues to improve past the release.  The link to this
living
>> >>> document is
>> >>> >> to be determined.
>> >>> >> >
>> >>> >> > TODO:  Docs need help on the new features in the 4.0 release.
>> >>>  Specifically
>> >>> >> we need help with Niciria Integration and Caringo documentation.
>> >>> >> >
>> >>> >> > QA Status
>> >>> >> > QA is proceeding through the test cycle.  It is currently
at 45%
>> of
>> >>> completion.
>> >>> >> The number of bugs generated from the tests have been minimum
so the
>> >>> >> quality of the release currently looks pretty good.
>> >>> >> >
>> >>> >> > Release Plan
>> >>> >> > - The current plan is for QA to complete its test cycle
between
>> >>> 9/26-9/28.
>> >>> >> > - When QA decides the test cycle is read, we will cut
a RC1
>> release.
>> >>> >> > - We are currently pushing to clear bugs generated from
the test
>> >>> cycle asap.
>> >>> >> > - After all P1 and P2 bugs are cleared, 4.0 release will
be
>> >>> submitted for
>> >>> >> approval to announce.
>> >>> >> >
>> >>> >> > --Alex
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> NS
>> >>
>> >
>> >
>> >
>> > --
>> > NS
>>
>
>
>
> --
> NS

Mime
View raw message