accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Thu, 03 Apr 2014 21:28:51 GMT
Some ASF definitions:

>From the ASF Voting Process page[1]

To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a security
exposure, negatively affects performance, *etc.* ). A veto without a
justification is invalid and has no weight.

So an individual already cannot veto "just because" and must provide a
reason. From our bylaws:

A valid, binding veto cannot be overruled. If a veto is cast, it must be
accompanied by a valid reason explaining the veto. The validity of a veto,
if challenged, can be confirmed by anyone who has a binding vote. This does
not necessarily signify agreement with the veto, but merely that the veto
is valid.

If you disagree with a valid veto, you must lobby the person casting the
veto to withdraw their veto. If a veto is not withdrawn, the action that
has been vetoed must be reversed in a timely manner.

So it looks like we've got that part covered. Further, from the ASF
glossary on veto[2]
According to the Apache methodology, a change which has been made or
proposed may be made moot through the exercise of a veto by a committer to
the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in
question. If the
R-T-C<http://www.apache.org/foundation/glossary.html#ReviewThenCommit>commit
policy is in effect, a veto prevents the change from being made. In
either the R-T-C or
C-T-R<http://www.apache.org/foundation/glossary.html#CommitThenReview>environments,
a veto applied to a change that has already been made forces
it to be reverted. Vetos may not be overridden nor voted down, and only
cease to apply when the committer who issued the veto withdraws it. All
vetos *must* be accompanied by a valid technical justification; a veto
without such a justification is invalid; in case of doubt, deciding whether
a technical justification is valid is up to the PMC. Vetos force discussion
and, if supported, version control rollback or appropriate code changes.
Vetoed code commits are best reverted by the original committer, unless an
urgent solution is needed (e.g., build breakers). Vetos only apply to code
changes; they do not apply to procedural issues such as software releases.

Based on this, a veto can only be applied to code, not to process. Changing
the bylaws is a matter of process, not code, and I feel that it should be
majority for consistency with the rest of the ASF.


[1] https://www.apache.org/foundation/voting.html#Veto

[2] http://www.apache.org/foundation/glossary.html#Veto


On Thu, Apr 3, 2014 at 2:04 PM, Keith Turner <keith@deenlo.com> wrote:

> On Thu, Apr 3, 2014 at 4:57 PM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > <opinion owner="bill_h" validity="dubious">
> > Voting is not a substitute for deliberation, working as a group to
> generate
> > agreement on decisions. First, those involved get together and hash out
> the
> > details, and then at some point there is a vote on the outcome of those
> > deliberations. (Unless you're Congress. ZING) Deliberation can take a
> long
> > time ... a really long time. And it's not usually fun. At some point you
> > just must call it.
> >
> > I don't like consensus approval for bylaw changes because someone could
> > torpedo the vote and ruin the extensive work that went into getting
> there.
> > It can actually discourage being involved in the deliberative process,
> > because you could always just jump in at the vote time and veto, either
> for
> > a well thought-out reason or just because. That's not fair to everyone
> who
> >
>
> No one should be able to veto "just because".  A veto should have a
> defensible reason.  Also if someone is not willing to defend their veto, is
> it valid?  If someone votes -1 and never answers questions about their
> position, can that vote be ignored?
>
>
> > spent lots of time deliberating, compromising, exploring. (Harshness
> > warning.) If you really had an issue, you should have brought it up
> before
> > the vote was called so the community could spend proper time on it.
> Voting
> > time isn't the appropriate time to discover fundamental issues with what
> > you're voting on.
> >
> > Also, in life, you don't always get what you want, and you don't always
> get
> > it perfect the first time. Majority approval lets a group get something
> > good enough, even with some problems and disagreement, started, or
> > progressing. You can then begin a new round of deliberations, and vote on
> > modifications to make it even better.
> >
> > Even if that modification is changing to consensus approval for bylaw
> > changes.
> > </opinion>
> >
> > If the XML tag wasn't signal enough, this is really my opinion. Part of
> > this is working out, as a community, how we make decisions, so you should
> > certainly form your own opinion and apply it to the current vote and
> future
> > ones.
> >
> >
> > On Thu, Apr 3, 2014 at 4:29 PM, Mike Drob <madrob@cloudera.com> wrote:
> >
> > > bhavanki: can you expand on why you didn't like consensus approval for
> > the
> > > bylaws?
> > >
> > >
> > > On Thu, Apr 3, 2014 at 1:13 PM, Bill Havanki <
> bhavanki@clouderagovt.com
> > > >wrote:
> > >
> > > > I dug into the dev archives for how the approval definition got set.
> > > > Originally, from the ZooKeeper bylaws [1], modification required 2/3
> > > > majority of ALL PMC members to +1 in order to pass. Billie didn't
> > prefer
> > > > that since it isn't an ASF-defined vote, and suggested consensus [2]
> > > > (February 26).
> > > >
> > > > I didn't like that and preferred majority since (surprise!) I didn't
> > like
> > > > the idea of a veto. I preferred majority approval. [next in thread
> > after
> > > 2]
> > > > Billie said she was neutral about that [second in thread after 2].
> So,
> > I
> > > > set it to majority approval and said anyone can switch it to
> consensus,
> > > > that would be fine [3] (March 4). No one changed it. So, here we are.
> > > >
> > > > The ASF voting guidelines [4] only discuss vetoes in the context of
> > code
> > > > modification. Its section on Procedural Votes is unhelpfully empty.
> > > > However, at the top it says:
> > > >
> > > > Votes on procedural issues follow the common format of majority rule
> > > unless
> > > > otherwise stated. That is, if there are more favourable votes than
> > > > unfavourable ones, the issue is considered to have passed --
> regardless
> > > of
> > > > the number of votes in each category. (If the number of votes seems
> too
> > > > small to be representative of a community consensus, the issue is
> > > typically
> > > > not pursued. However, see the description of lazy consensus for a
> > > modifying
> > > > factor.)
> > > >
> > > >
> > > > When I called this vote, I decided that since the bylaws stated
> > majority
> > > > approval for modifications, the vote should be majority approval.
> There
> > > was
> > > > time for the community to deliberate about it before the vote, so
> > absent
> > > > any concern (that I recall seeing) it was the consistent choice. (In
> > > fact,
> > > > the first vote Mike called on March 10 was also majority approval.)
> > > >
> > > > That is my rationale for majority approval in this vote.
> > > >
> > > > Bill
> > > >
> > > > [1] http://zookeeper.apache.org/bylaws.html
> > > > [2]
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201402.mbox/%3CCAF1jEfDsHU_tG94TNs-=Mss65geDp2yvxEmpGR1KzQ5Gsb-+9A@mail.gmail.com%3E
> > > > [3]
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201403.mbox/%3CCAD-fFU+SX7aE0cMu5AC9xVR0OxwGeMm-V0O0rNpeQCnxuvAr0Q@mail.gmail.com%3E
> > > > [4] http://www.apache.org/foundation/voting.html
> > > >
> > > >
> > > > On Thu, Apr 3, 2014 at 4:03 PM, Christopher <ctubbsii@apache.org>
> > wrote:
> > > >
> > > > > Unfortunately, I think I'm going to have to change my vote to a -1,
> > > > > based on the point that John just brought up.
> > > > >
> > > > > After some thought, I'm not sure it makes sense for people to be
> > bound
> > > > > by operating rules they did not agree to, especially for the
> initial
> > > > > adoption. I think consensus approval makes more sense for modifying
> > > > > the bylaws (and for the initial adoption of those bylaws) than does
> > > > > majority approval.
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > > >
> > > > > On Thu, Apr 3, 2014 at 3:32 PM, John Vines <vines@apache.org>
> wrote:
> > > > > > I'm also wondering if modifying bylaws, for now and in the
> future,
> > > > should
> > > > > > be consensus approval. Why is that scaled down to Majority?
> > > > > >
> > > > > >
> > > > > > On Thu, Apr 3, 2014 at 3:13 PM, John Vines <jvines@gmail.com>
> > wrote:
> > > > > >
> > > > > >> -1
> > > > > >>
> > > > > >> There is still no clarity on code change actions, which
I think
> > need
> > > > to
> > > > > be
> > > > > >> resolved before it should pass. It seems to be ambiguous,
> > > > intentionally,
> > > > > >> with the intent to revise later. If that's the case, it
should
> > just
> > > be
> > > > > >> removed until a more definitive guideline can be put in
place.
> Or
> > > just
> > > > > >> point at an existing CTR guideline.
> > > > > >>
> > > > > >>
> > > > > >> On Thu, Apr 3, 2014 at 2:18 PM, Bill Havanki <
> > > > bhavanki@clouderagovt.com
> > > > > >wrote:
> > > > > >>
> > > > > >>> Reminder to all: the bylaw vote ends at 10 AM EDT /
7 AM PDT
> > > tomorrow
> > > > > >>> morning. Majority approval is required.
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Bill
> > > > > >>>
> > > > > >>>
> > > > > >>> On Thu, Apr 3, 2014 at 2:13 PM, Mike Drob <madrob@cloudera.com
> >
> > > > wrote:
> > > > > >>>
> > > > > >>> > +1
> > > > > >>> >
> > > > > >>> >
> > > > > >>> > On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <
> > > eric.newton@gmail.com
> > > > >
> > > > > >>> wrote:
> > > > > >>> >
> > > > > >>> > > +1
> > > > > >>> > >
> > > > > >>> > > Thank you all for working through something
that makes me
> > want
> > > to
> > > > > go
> > > > > >>> back
> > > > > >>> > > to reading gigabytes of debug logs.
> > > > > >>> > >
> > > > > >>> > > -Eric
> > > > > >>> > >
> > > > > >>> > >
> > > > > >>> > >
> > > > > >>> > > On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi
<
> > > > billie@apache.org>
> > > > > >>> > wrote:
> > > > > >>> > >
> > > > > >>> > > > Hey everyone!  We only have 3 more days
to vote on
> > Accumulo's
> > > > > bylaws
> > > > > >>> > ...
> > > > > >>> > > >
> > > > > >>> > > >
> > > > > >>> > > > On Fri, Mar 28, 2014 at 6:55 AM, Bill
Havanki <
> > > > > >>> > bhavanki@clouderagovt.com
> > > > > >>> > > > >wrote:
> > > > > >>> > > >
> > > > > >>> > > > > Please vote on the proposed bylaws,
as available at
> > > > > >>> > > > >
> > > > > >>> > > > > *
> > > > > >>> > > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup
> > > > > >>> > > > > <
> > > > > >>> > > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup
> > > > > >>> > > > > >*
> > > > > >>> > > > >
> > > > > >>> > > > > A nicer-to-read version is available
at
> > > > > >>> > > > >
> > > > > >>> > > > > http://accumulo.apache.org/bylaws.html
> > > > > >>> > > > >
> > > > > >>> > > > > This vote will be open for 7 days,
until 4 April 2014
> > 14:00
> > > > > UTC.
> > > > > >>> > > > >
> > > > > >>> > > > > Upon successful completion of this
vote, the first line
> > of
> > > > the
> > > > > >>> > document
> > > > > >>> > > > > body
> > > > > >>> > > > > will be replaced with "This is version
1 of the
> bylaws,"
> > > and
> > > > > the
> > > > > >>> > > > statement
> > > > > >>> > > > > defining the document as a draft
will be stricken.
> > > > > Additionally, a
> > > > > >>> > link
> > > > > >>> > > > to
> > > > > >>> > > > > the document will be added to the
navigation menu.
> > > > > >>> > > > >
> > > > > >>> > > > > This vote requires majority approval
to pass: at least
> 3
> > +1
> > > > > votes
> > > > > >>> and
> > > > > >>> > > > more
> > > > > >>> > > > > +1
> > > > > >>> > > > > than -1's.
> > > > > >>> > > > >
> > > > > >>> > > > > [ ] +1 - "I approve of these proposed
bylaws and accept
> > > them
> > > > > for
> > > > > >>> the
> > > > > >>> > > > > Apache Accumulo
> > > > > >>> > > > > project."
> > > > > >>> > > > > [ ] +0 - "I neither approve nor
disapprove of these
> > > proposed
> > > > > >>> bylaws,
> > > > > >>> > > but
> > > > > >>> > > > > accept them for the Apache Accumulo
project."
> > > > > >>> > > > > [ ] -1 - "I do not approve of these
proposed bylaws and
> > do
> > > > not
> > > > > >>> accept
> > > > > >>> > > > them
> > > > > >>> > > > > for
> > > > > >>> > > > > the Apache Accumulo project because..."
> > > > > >>> > > > >
> > > > > >>> > > > > Thank you.
> > > > > >>> > > > >
> > > > > >>> > > > > --
> > > > > >>> > > > > // Bill Havanki
> > > > > >>> > > > > // Solutions Architect, Cloudera
Govt Solutions
> > > > > >>> > > > > // 443.686.9283
> > > > > >>> > > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> // Bill Havanki
> > > > > >>> // Solutions Architect, Cloudera Govt Solutions
> > > > > >>> // 443.686.9283
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Cheers
> > > > > >> ~John
> > > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > // Bill Havanki
> > > > // Solutions Architect, Cloudera Govt Solutions
> > > > // 443.686.9283
> > > >
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message