atom feed17 messages in org.apache.incubator.cloudstack-devRe: [VOTE] CloudStack Release 4.0, fi...
FromSent OnAttachments
Alex HuangOct 5, 2012 7:53 am 
Wido den HollanderOct 5, 2012 7:56 am 
Chip ChildersOct 5, 2012 8:00 am 
Alex HuangOct 5, 2012 8:14 am 
Chip ChildersOct 5, 2012 8:20 am 
Chip ChildersOct 5, 2012 8:23 am 
David NalleyOct 5, 2012 8:32 am 
Brett PorterOct 5, 2012 9:11 am 
Brett PorterOct 5, 2012 9:14 am 
Brett PorterOct 5, 2012 9:16 am 
Chip ChildersOct 5, 2012 9:22 am 
Brett PorterOct 5, 2012 9:28 am 
Chip ChildersOct 5, 2012 9:30 am 
Alex HuangOct 5, 2012 9:37 am 
Brett PorterOct 5, 2012 9:40 am 
Noah SlaterOct 5, 2012 1:48 pm 
Noah SlaterOct 5, 2012 1:51 pm 
Subject:Re: [VOTE] CloudStack Release 4.0, first round
From:Noah Slater (nsla@tumbolia.org)
Date:Oct 5, 2012 1:48:37 pm
List:org.apache.incubator.cloudstack-dev

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 <bre@apache.org> wrote:

On 06/10/2012, at 2:30 AM, Chip Childers <chip@sungard.com> wrote:

On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers <chip@sungard.com> wrote:

On Fri, Oct 5, 2012 at 12:16 PM, Brett Porter <bre@apache.org> wrote:

Hi Alex,

On 06/10/2012, at 12:54 AM, Alex Huang <Alex@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?

[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