incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [VOTE] CloudStack Release 4.0, first round
Date Fri, 05 Oct 2012 16:12:06 GMT

On 06/10/2012, at 1:33 AM, David Nalley <david@gnsa.us> wrote:

> On Fri, Oct 5, 2012 at 11:15 AM, Alex Huang <Alex.Huang@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





Mime
View raw message