18 messages in org.apache.incubator.cloudstack-devRe: [AFSCS40] Release status for CS 4.0| From | Sent On | Attachments |
|---|---|---|
| Alex Huang | Sep 24, 2012 7:26 pm | |
| Chip Childers | Sep 24, 2012 8:13 pm | |
| Ram Ganesh | Sep 24, 2012 10:48 pm | |
| Alex Huang | Sep 25, 2012 12:07 pm | |
| Alex Huang | Sep 25, 2012 12:08 pm | |
| Chip Childers | Sep 25, 2012 12:13 pm | |
| Vijay Venkatachalam | Sep 26, 2012 8:24 am | |
| Alex Huang | Sep 26, 2012 11:21 am | |
| Radhika Puthiyetath | Sep 26, 2012 9:51 pm | |
| Hugo Trippaers | Sep 29, 2012 3:35 pm | |
| Radhika Puthiyetath | Sep 29, 2012 8:44 pm | |
| Noah Slater | Sep 30, 2012 4:22 am | |
| Noah Slater | Sep 30, 2012 10:08 am | |
| Noah Slater | Sep 30, 2012 10:09 am | |
| Chip Childers | Oct 1, 2012 8:22 am | |
| Chip Childers | Oct 1, 2012 8:29 am | |
| Noah Slater | Oct 2, 2012 1:50 pm | |
| ronald higgins | Nov 1, 2012 1:40 am |
| Subject: | Re: [AFSCS40] Release status for CS 4.0 | |
|---|---|---|
| From: | Noah Slater (nsla...@tumbolia.org) | |
| Date: | Oct 2, 2012 1:50:33 pm | |
| List: | org.apache.incubator.cloudstack-dev | |
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...@sungard.com>wrote:
On Sun, Sep 30, 2012 at 1:09 PM, Noah Slater <nsla...@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 <nsla...@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...@sungard.com>wrote:
On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <Alex...@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...@sungard.com] Sent: Monday, September 24, 2012 8:14 PM To: <clou...@incubator.apache.org> Cc: clou...@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...@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