Thanks Bret, you covered all the points I had floating in my head! Heh. The only additional thing I would say is: release VOTES are expensive.
Now, this is just my personal experience. But a VOTE is a public call for everyone and anyone to go download this source artefact, and run through this wiki page, and follow all these instructions. And typically, you will find that newbs who are interested in contributing to the project will take this as an opportunity to be involved. Which is fscking great! (I usually Tweet from the official Twitter account, and most committers will RT, links to the VOTE thread, with invitations to "get stuck in.") The only problem with this is that when you're dealing with 20, 30 people who are all running through this testing procedure, you better be pretty damn sure your shit is gonna work. Or people's efforts will feel wasted, and they will stop bothering. This is, primarily, why I started doing RFCs. I wanted to a much more low-key way of saying "hey guys, I sorta think this is maybe ready to ship. Can all the committers take a look and make sure we have everything in order?" As for version numbers, if I am releasing 4.0.0, and there are three rounds of voting. I will build the 4.0.0 release three times and upload them to my public space on people.a.o. I don't change the version number, or anything. Because ultimately, it doesn't matter. I actually just remove the original artefacts and replace them each time. All that matters is that when you send that VOTE email out, the artefacts that people are downloading have been built from the tree-ish you said they were built from. (Which, if your test procedure is detailed enough, should be easily verifiable.) And as Bret mentioned, we could call it 4.0.0.b (for beta, or whatever) if we want to indicate our beta status. But it might be better to just indicate this in the README or CHANGELOG or whatever. And keep our terminology to nightlies (automated builds prepared for the developers only), pre-release builds (the things you're preparing in the run-up to a VOTE), releases, and binary builds (The things we build from the releases for the convenience of our users.). (Which, as Bret points out, we would never, ever use to VOTE on.) On Fri, Oct 5, 2012 at 5:40 PM, Brett Porter <br...@apache.org> wrote: > > On 06/10/2012, at 2:30 AM, Chip Childers <chip.child...@sungard.com> > wrote: > > > On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers > > <chip.child...@sungard.com> wrote: > >> On Fri, Oct 5, 2012 at 12:16 PM, Brett Porter <br...@apache.org> wrote: > >>> Hi Alex, > >>> > >>> On 06/10/2012, at 12:54 AM, Alex Huang <alex.hu...@citrix.com> wrote: > >>> > >>>> Please follow the test procedure before voting: > >>>> > >>>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure > >>> > >>> I noticed the instructions rely on importing keys from a key server, > after downloading the KEYS file. Wouldn't it be better to import the KEYS > file directly instead? > >> > >> Brett, > >> > >> I followed the CouchDB test procedure document [1] as the template for > >> that verification step. Is it more common to use the KEYS file? > >> > >> -chip > >> > >> [1] http://wiki.apache.org/couchdb/Test_procedure > > > > I also note that the httpd project suggests the key server as well: > > > > http://httpd.apache.org/dev/verification.html > > > > Good point - though it then goes onto a lengthy discussion about how you > can't trust it until you verify the key, by meeting Sander, etc. :) > > - Brett -- NS
