Re: [AFSCS40] Release status for CS 4.0

[Chip Childers <ch...@sungard.com>]

On Sun, Sep 30, 2012 at 7:23 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Chip,
>
> Can you point me to where you're hosting these builds?

p.a.o/~chipchilders/cloudstack/4.0 - exactly where they are supposed to go. ;-)

> 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

Good reminder.

> (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.)

Agreed on the RC not being part of an actual release candidate's
version number, due to the nature of the voting / distribution
process.

> 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".

+1 to calling them something besides release notes

>
> On Tue, Sep 25, 2012 at 8:13 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Al...@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: <cl...@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 <Al...@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