accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Thu, 03 Apr 2014 21:36:42 GMT
By those glossary definitions, we're misusing veto throughout the majority
of our bylaws, so we need to rewrite them to clarify the terminology,
either by rewording it to not use veto or to redefine veto for our project.


On Thu, Apr 3, 2014 at 5:28 PM, Mike Drob <madrob@cloudera.com> wrote:

> 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