cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [VOTE] CloudStack Release 4.0, first round
Date Fri, 05 Oct 2012 20:49:00 GMT
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

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 <> wrote:

> On 06/10/2012, at 2:30 AM, Chip Childers <>
> wrote:
> > On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers
> > <> wrote:
> >> On Fri, Oct 5, 2012 at 12:16 PM, Brett Porter <> wrote:
> >>> Hi Alex,
> >>>
> >>> On 06/10/2012, at 12:54 AM, Alex Huang <> wrote:
> >>>
> >>>> Please follow the test procedure before voting:
> >>>>
> >>>>
> >>>
> >>> 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]
> >
> > I also note that the httpd project suggests the key server as well:
> >
> >
> >
> 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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message