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 <alex.hu...@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
