Personally, while not voting -1, I still don't quite agree that pushing
the first draft of a document to a successful vote that has dissent from
more than one PMC member.
To my knowledge, there is no rush to release such a document, so it
doesn't make sense to me to release such a document to just turn around
and make an amendment to it. Let's get it right the first time and not
set a precedent for ignoring the concerns. Community comes first.
Presently, my biggest concern is that there is still some ambiguity
about the lazy approval of code changes that John initial brought up. I
haven't thought enough about the majority versus consensus rules, but my
first impression is, that with good faith, this isn't a big concern that
needs to be hashed up front.
Lastly, I want to applaud Bill for stepping up to spearhead this. The
frustration with this process, akin to that which we face for every
release, is unavoidable. No, the community as a whole does not always
(ever?) read everything up front, and that is the difficulty in working
as a group. However, I do not feel like just because someone missed the
"preferred" time window to voice a concern means that those concerns are
no longer valid at the given moment. Just as we wouldn't treat an issue
found in an RC during the last hour of the vote differently than an
issue found before the RC was made (everyone would much rather the
latter always be the case), discussion that was raised late in the game
is just as important as discussion raised before the approval vote.
On 4/3/14, 8:14 PM, Sean Busbey wrote:
Could the -1 voters please explain what we can't fix with a follow on
modification to the bylaws after this vote?
Even on the matter of consensus vs majority approval for bylaw
modifications, it is relatively easy for a follow on vote to make this
change. It is no more difficult, say, than starting another vote after this
one fails. Certainly, it is easier than the reverse transition would be.
-Sean
On Thu, Apr 3, 2014 at 6:43 PM, Mike Drob <[email protected]> wrote:
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.
