You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alex Huang <Al...@citrix.com> on 2012/10/05 16:54:13 UTC
[VOTE] CloudStack Release 4.0, first round
Hello,
I would like call a vote for the Apache CloudStack 4.0.0 release, first round.
We encourage the whole community to download and test these release
artifacts so that any critical issues can be resolved before the release is
made. Everyone is free to vote on this release.
We are voting on the beta6 release artifacts available under:
http://people.apache.org/~chipchilders/cloudstack/4.0/
These artifacts have been built from the following tree-ish in Git:
33ae7ef3afee20247fc753c3e8bed766b0cd04e6
Please follow the test procedure before voting:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure
Thank you.
Happy voting,
--Alex
RE: [VOTE] CloudStack Release 4.0, first round
Posted by Alex Huang <Al...@citrix.com>.
> Yes, you should call a vote expecting it to pass. Releases can't be vetoed, so it
> should be pretty serious objections to stop at that point.
>
> For the mechanism beyond that, it can go either way - communities I've been
> involved in generally reach some consensus by testing RC labeled bundles
> before voting on the final release. I find this helpful because otherwise you
> get votes mixed in with issues and it can be hard to ascertain what the result
> really is.
>
> I believe some others will vote earlier, and roll a new version number if the
> vote fails. These are typically mature projects that tend to have their votes
> succeed in most cases.
>
> I would avoid rolling 4.0.0 multiple times, as that is likely to cause confusion
> about which is the real one.
>
> Worth bearing in mind for the future too, you can certainly release
> something and label it alpha/beta/milestone and then release the GA later.
> Releases of source code don't attribute any particular meaning to its level of
> maturity, QA or marketability other than how you choose to label it.
>
Got it. Thanks for the explanation there. Looks like I jumped the gun on that call. I'll reissue this once the current bugs are done.
--Alex
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Brett Porter <br...@apache.org>.
On 06/10/2012, at 1:33 AM, David Nalley <da...@gnsa.us> wrote:
> On Fri, Oct 5, 2012 at 11:15 AM, Alex Huang <Al...@citrix.com> wrote:
>>> Alex,
>>>
>>> A couple of issues.
>>>
>>> First, we shouldn't be voting on the "beta" release artifacts. I need to cut a
>>> proper 4.0.0 build for us to vote on.
>>>
>>> Second, there are still several bugs that I consider to be blockers outstanding
>>> right now.
>>>
>>> Unfortunately, my vote is -1 for this VOTE thread, based on the reasons
>>> above.
>>
>> Chip,
>>
>> Can you cut a proper build? This is for a first round of voting. I don't expect the first round to pass but I like to put all this out there for people to test. I understand a few bugs came in last night but I think the product is largely ready for people to test because QA testing is at 93% complete yesterday.
>>
>> After Wednesday discussion on IRC, I realized we should have been doing this already. Technically we're really at fourth or fifth round now because QA has been taking builds and testing and has been in effect voting -1 on the release. I've been running it like a enterprise-like release process and that's my fault for doing so.
>>
>> I think the next few rounds will come very quickly because we're only going to fix the blockers that we've found.
>>
>> --Alex
>
>
> IMO we shouldn't be voting if we don't expect it to pass. There are
> still a few problems that really need to be fixed before we kick
> something out the door.
> If I were to vote on the specfic beta6 build it would also be a -1(binding)
Yes, you should call a vote expecting it to pass. Releases can't be vetoed, so it should be pretty serious objections to stop at that point.
For the mechanism beyond that, it can go either way - communities I've been involved in generally reach some consensus by testing RC labeled bundles before voting on the final release. I find this helpful because otherwise you get votes mixed in with issues and it can be hard to ascertain what the result really is.
I believe some others will vote earlier, and roll a new version number if the vote fails. These are typically mature projects that tend to have their votes succeed in most cases.
I would avoid rolling 4.0.0 multiple times, as that is likely to cause confusion about which is the real one.
Worth bearing in mind for the future too, you can certainly release something and label it alpha/beta/milestone and then release the GA later. Releases of source code don't attribute any particular meaning to its level of maturity, QA or marketability other than how you choose to label it.
- Brett
Re: [VOTE] CloudStack Release 4.0, first round
Posted by David Nalley <da...@gnsa.us>.
On Fri, Oct 5, 2012 at 11:15 AM, Alex Huang <Al...@citrix.com> wrote:
>> Alex,
>>
>> A couple of issues.
>>
>> First, we shouldn't be voting on the "beta" release artifacts. I need to cut a
>> proper 4.0.0 build for us to vote on.
>>
>> Second, there are still several bugs that I consider to be blockers outstanding
>> right now.
>>
>> Unfortunately, my vote is -1 for this VOTE thread, based on the reasons
>> above.
>
> Chip,
>
> Can you cut a proper build? This is for a first round of voting. I don't expect the first round to pass but I like to put all this out there for people to test. I understand a few bugs came in last night but I think the product is largely ready for people to test because QA testing is at 93% complete yesterday.
>
> After Wednesday discussion on IRC, I realized we should have been doing this already. Technically we're really at fourth or fifth round now because QA has been taking builds and testing and has been in effect voting -1 on the release. I've been running it like a enterprise-like release process and that's my fault for doing so.
>
> I think the next few rounds will come very quickly because we're only going to fix the blockers that we've found.
>
> --Alex
IMO we shouldn't be voting if we don't expect it to pass. There are
still a few problems that really need to be fixed before we kick
something out the door.
If I were to vote on the specfic beta6 build it would also be a -1(binding)
--David
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Oct 5, 2012 at 11:15 AM, Alex Huang <Al...@citrix.com> wrote:
>> Alex,
>>
>> A couple of issues.
>>
>> First, we shouldn't be voting on the "beta" release artifacts. I need to cut a
>> proper 4.0.0 build for us to vote on.
>>
>> Second, there are still several bugs that I consider to be blockers outstanding
>> right now.
>>
>> Unfortunately, my vote is -1 for this VOTE thread, based on the reasons
>> above.
>
> Chip,
>
> Can you cut a proper build? This is for a first round of voting. I don't expect the first round to pass but I like to put all this out there for people to test. I understand a few bugs came in last night but I think the product is largely ready for people to test because QA testing is at 93% complete yesterday.
>
> After Wednesday discussion on IRC, I realized we should have been doing this already. Technically we're really at fourth or fifth round now because QA has been taking builds and testing and has been in effect voting -1 on the release. I've been running it like a enterprise-like release process and that's my fault for doing so.
>
> I think the next few rounds will come very quickly because we're only going to fix the blockers that we've found.
>
> --Alex
>
Alex,
Great explanation of your intent. Thanks.
I just sent out specifics that are causing my -1 vote. I'd like to
see that we make some progress on those bugs before starting another
vote thread though... I think that we can use this current thread to
find other people's concerns.
If we make a bunch of progress on the bugs I listed today, I don't
disagree with cutting a 4.0.0 version build and restarting a vote this
afternoon.
Fair?
RE: [VOTE] CloudStack Release 4.0, first round
Posted by Alex Huang <Al...@citrix.com>.
> Alex,
>
> A couple of issues.
>
> First, we shouldn't be voting on the "beta" release artifacts. I need to cut a
> proper 4.0.0 build for us to vote on.
>
> Second, there are still several bugs that I consider to be blockers outstanding
> right now.
>
> Unfortunately, my vote is -1 for this VOTE thread, based on the reasons
> above.
Chip,
Can you cut a proper build? This is for a first round of voting. I don't expect the first round to pass but I like to put all this out there for people to test. I understand a few bugs came in last night but I think the product is largely ready for people to test because QA testing is at 93% complete yesterday.
After Wednesday discussion on IRC, I realized we should have been doing this already. Technically we're really at fourth or fifth round now because QA has been taking builds and testing and has been in effect voting -1 on the release. I've been running it like a enterprise-like release process and that's my fault for doing so.
I think the next few rounds will come very quickly because we're only going to fix the blockers that we've found.
--Alex
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Oct 5, 2012 at 11:00 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Fri, Oct 5, 2012 at 10:54 AM, Alex Huang <Al...@citrix.com> wrote:
>> Hello,
>>
>> I would like call a vote for the Apache CloudStack 4.0.0 release, first round.
>>
>> We encourage the whole community to download and test these release
>> artifacts so that any critical issues can be resolved before the release is
>> made. Everyone is free to vote on this release.
>>
>> We are voting on the beta6 release artifacts available under:
>>
>> http://people.apache.org/~chipchilders/cloudstack/4.0/
>>
>> These artifacts have been built from the following tree-ish in Git:
>>
>> 33ae7ef3afee20247fc753c3e8bed766b0cd04e6
>>
>> Please follow the test procedure before voting:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure
>>
>> Thank you.
>>
>> Happy voting,
>>
>> --Alex
>>
>
> Alex,
>
> A couple of issues.
>
> First, we shouldn't be voting on the "beta" release artifacts. I need
> to cut a proper 4.0.0 build for us to vote on.
>
> Second, there are still several bugs that I consider to be blockers
> outstanding right now.
>
> Unfortunately, my vote is -1 for this VOTE thread, based on the reasons above.
Adding specifics:
Blockers:
CLOUDSTACK-263
CLOUDSTACK-260
CLOUDSTACK-259
CLOUDSTACK-257
CLOUDSTACK-248
Critical (IMO should be resolved for 4.0.0):
CLOUDSTACK-264
CLOUDSTACK-216
Also Critical, but should be triaged: CLOUDSTACK-267
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Oct 5, 2012 at 10:54 AM, Alex Huang <Al...@citrix.com> wrote:
> Hello,
>
> I would like call a vote for the Apache CloudStack 4.0.0 release, first round.
>
> We encourage the whole community to download and test these release
> artifacts so that any critical issues can be resolved before the release is
> made. Everyone is free to vote on this release.
>
> We are voting on the beta6 release artifacts available under:
>
> http://people.apache.org/~chipchilders/cloudstack/4.0/
>
> These artifacts have been built from the following tree-ish in Git:
>
> 33ae7ef3afee20247fc753c3e8bed766b0cd04e6
>
> Please follow the test procedure before voting:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure
>
> Thank you.
>
> Happy voting,
>
> --Alex
>
Alex,
A couple of issues.
First, we shouldn't be voting on the "beta" release artifacts. I need
to cut a proper 4.0.0 build for us to vote on.
Second, there are still several bugs that I consider to be blockers
outstanding right now.
Unfortunately, my vote is -1 for this VOTE thread, based on the reasons above.
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Brett Porter <br...@apache.org>.
On 06/10/2012, at 2:23 AM, Chip Childers <ch...@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 <Al...@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?
The doc says...
"You will need to import the keys into your local keychain before you can continue.
You can do this manually, from the KEYS file.
Or, you can import them from a public key server:"
There is more info here: http://www.apache.org/dev/release-signing#public-key-not-found
If you download from a key server, you need to trust it and check the fingerprint matches. Importing the keys file is typically quicker and more trustworthy.
- Brett
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Noah Slater <ns...@tumbolia.org>.
*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 <ns...@tumbolia.org> 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 <br...@apache.org> wrote:
>
>>
>> On 06/10/2012, at 2:30 AM, Chip Childers <ch...@sungard.com>
>> wrote:
>>
>> > On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers
>> > <ch...@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 <Al...@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
>
--
NS
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Noah Slater <ns...@tumbolia.org>.
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 <ch...@sungard.com>
> wrote:
>
> > On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers
> > <ch...@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 <Al...@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
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Brett Porter <br...@apache.org>.
On 06/10/2012, at 2:30 AM, Chip Childers <ch...@sungard.com> wrote:
> On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers
> <ch...@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 <Al...@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
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Oct 5, 2012 at 12:23 PM, Chip Childers
<ch...@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 <Al...@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
However, I have updated the instructions to include the option of
importing from the KEYS file as well.
Thanks for pointing this out!
-chip
>
>> - Brett
>>
>>
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Chip Childers <ch...@sungard.com>.
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 <Al...@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
> - Brett
>
>
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Brett Porter <br...@apache.org>.
Hi Alex,
On 06/10/2012, at 12:54 AM, Alex Huang <Al...@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
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Brett Porter <br...@apache.org>.
On 06/10/2012, at 12:57 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> On 10/05/2012 04:54 PM, Alex Huang wrote:
>> Hello,
>>
>> I would like call a vote for the Apache CloudStack 4.0.0 release, first round.
>>
>> We encourage the whole community to download and test these release
>> artifacts so that any critical issues can be resolved before the release is
>> made. Everyone is free to vote on this release.
>>
>> We are voting on the beta6 release artifacts available under:
>>
>> http://people.apache.org/~chipchilders/cloudstack/4.0/
>>
>
> I've just build and pushed the Debian packages to cloudstack.apt-get.eu, these can be used for easier testing.
>
Just to clarify - while these are certainly convenient for testing and reporting issues leading up to a vote, they aren't suitable for basing a vote on - that needs to be about the source code being released from ASF hardware.
- Brett
Re: [VOTE] CloudStack Release 4.0, first round
Posted by Wido den Hollander <wi...@widodh.nl>.
On 10/05/2012 04:54 PM, Alex Huang wrote:
> Hello,
>
> I would like call a vote for the Apache CloudStack 4.0.0 release, first round.
>
> We encourage the whole community to download and test these release
> artifacts so that any critical issues can be resolved before the release is
> made. Everyone is free to vote on this release.
>
> We are voting on the beta6 release artifacts available under:
>
> http://people.apache.org/~chipchilders/cloudstack/4.0/
>
I've just build and pushed the Debian packages to cloudstack.apt-get.eu,
these can be used for easier testing.
Wido
> These artifacts have been built from the following tree-ish in Git:
>
> 33ae7ef3afee20247fc753c3e8bed766b0cd04e6
>
> Please follow the test procedure before voting:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure
>
> Thank you.
>
> Happy voting,
>
> --Alex
>