incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: [AFSCS40] Release status for CS 4.0
Date Sun, 30 Sep 2012 17:09:30 GMT
cf. http://www.apache.org/foundation/glossary.html

On Sun, Sep 30, 2012 at 6: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.
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message