Changing my vote to +0. While I think the bylaws are fine as is, and I think future issues can be fixed through follow on amendments, there are clearly issues that have not been resolved. I would like to see strong adoption for the first pass, and then majority for future issues.
On Thu, Apr 3, 2014 at 3:57 PM, Billie Rinaldi <[email protected]>wrote: > On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey <[email protected] > >wrote: > > > On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi <[email protected] > > >wrote: > > > > > On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki < > [email protected] > > > >wrote: > > > > > > > > > Going by the standards of a release vote, voting is actually the > > > appropriate time to discover fundamental issues. That's kind of the > > whole > > > point of voting -- getting people to agree that there are no > fundamental > > > issues with what you're voting on. Finding valid, justifiable issues > > > should be welcome, as it results in a better product, whether the > product > > > be a release or a community standard. > > > > > > > > > > > As an aside, this is not encouraged in our current release process. > > > > The test practices for a release take longer than the voting period for > an > > RC. This directly implies that the fundamental issues must have been > worked > > out prior to a call to vote. > > > > Our disagreement here might largely be due to differing definitions of > "fundamental issues." Also, I think you might be blocking out what > happened between the first 1.5.0 release candidate and the last? =) > > > > > > I've been fine with this interpretation, largely because it lines up with > > Apache guidelines around votes: do the consensus building work up front. > If > > we're going to use a release vote as a time to do primary vetting, then > we > > should probably change our RC vote window. > > >
