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 <nsla...@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.child...@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.child...@sungard.com>wrote: >> >> >> >>> On Tue, Sep 25, 2012 at 3:08 PM, Alex Huang <alex.hu...@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.child...@sungard.com] >> >>> >> Sent: Monday, September 24, 2012 8:14 PM >> >>> >> To: <cloudstack-us...@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.hu...@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
