accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Loss <bfl...@praxiseng.com>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Fri, 04 Apr 2014 12:57:21 GMT
-0

I don’t see the need to push something through that it sounds like we know we’re going
to change immediately, especially given that there is opposition to the proposed bylaws. 
What’s the down side of waiting to get it right now?

I do second Josh’s comments.  Thanks Bill and everyone else for the hard work on this!


On Apr 4, 2014, at 12:03 AM, Josh Elser <josh.elser@gmail.com> wrote:

> 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 <madrob@cloudera.com> 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 <billie.rinaldi@gmail.com
>>>> wrote:
>>> 
>>>> On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey <busbey+lists@cloudera.com
>>>>> wrote:
>>>> 
>>>>> On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi <
>>> billie.rinaldi@gmail.com
>>>>>> wrote:
>>>>> 
>>>>>> On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki <
>>>> bhavanki@clouderagovt.com
>>>>>>> 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.
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message