accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Fri, 04 Apr 2014 00:14:01 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message