*Columbo voice* One more thing! Alex, as RM, you should probably wrap this thread up with something like:
I am aborting this round. I will start round two once the outstanding issues have been addressed. Thank you for participating! On Fri, Oct 5, 2012 at 9:49 PM, Noah Slater <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> On 06/10/2012, at 2:30 AM, Chip Childers <[email protected]> >> wrote: >> >> > On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers >> > <[email protected]> wrote: >> >> On Fri, Oct 5, 2012 at 12:16 PM, Brett Porter <[email protected]> >> wrote: >> >>> Hi Alex, >> >>> >> >>> On 06/10/2012, at 12:54 AM, Alex Huang <[email protected]> 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 > -- NS
