accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 25 Nov 2014 20:48:02 GMT
On Tue, Nov 25, 2014 at 3:34 PM, Bill Havanki <bhavanki@clouderagovt.com>
wrote:

> I took a look at the review for the patch [1] and surveyed the comment
> stream for ACCUMULO-3176 in order to judge the validity of Sean's veto. I'm
> just looking at the veto, and not judging the merits of the change.
>
> ASF's voting process page [2] has this to say about validity.
>
> "To prevent vetos [sic] 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."
>
> Sean's veto has this as a justification: "*This change alters our public
> API while not solving the underlying issue of **race conditions in property
> updates.*"
>
> - The justification is certainly not capricious.
> - The justification is certainly of a technical nature.
> - The justification states that the change is bad because it changes the
> API without solving the underlying issue. I expand that, based on Sean's
> comments, to the assertion that the risk of changing the public API for a
> partial solution is too high, and should wait for a complete solution.
>

How long should we wait for someone to create a "complete solution"? If no
one ever does, do you feel Accumulo user will be better off?


> - The "showing" is in the review, which includes changes to the public API,
> and in commentary on the topic, which admits on all sides that the general
> problem isn't solved through it.
>
> Is the change "bad"? Is it "bad enough"? That could be considered, but I
> don't believe it is in the spirit of the process. The veto should propel
> further discussion and development of the solution; in fact, it already is.
>
> It is true that the justification does not pertain directly to the stated
> purpose of the change. However, this is not a cause for invalidity. A
> change could be vetoed for breaking unrelated unit tests, or opening a
> security hole, or slowing performance unacceptably.
>
> Based on the above, I deem the veto valid.
>
> [1] https://reviews.apache.org/r/26188/
> [2] http://www.apache.org/foundation/voting.html
>
>
>
> On Tue, Nov 25, 2014 at 1:30 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > I'm going to challenge the validity of that veto, because "solving the
> > underlying issue of race conditions in property updates" is not the
> > intended goal of the patch, or any stated side-effect. It also doesn't
> > preclude the pursuit of a solution for that issue. Comments about race
> > conditions for property updates was a related topic brought up in the
> JIRA
> > comments thread, not in the patch or the issue description. Rather, this
> > patch solves a very different problem: avoiding the need to alter
> > properties post-creation. This is an API improvement and helps in some
> > cases where properties are utilized immediately after creation, or
> anywhere
> > where somebody might want to create a table in fewer API calls.
> >
> > In accordance with our bylaws, another committer must now verify the
> > validity of your veto.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Tue, Nov 25, 2014 at 1:10 PM, Sean Busbey <busbey@cloudera.com>
> wrote:
> >
> > > -1
> > >
> > > This change alters our public API while not solving the underlying
> issue
> > of
> > > race conditions in property updates.
> > >
> > > On Tue, Nov 25, 2014 at 11:14 AM, Christopher <ctubbsii@apache.org>
> > wrote:
> > >
> > > > Committers, this is a consensus vote on whether or not to include
> > Jenna's
> > > > patch for ACCUMULO-3176 to the 1.7.0-SNAPSHOT (master) branch.
> > > >
> > > > This patch improves the table creation API with the introduction of a
> > > > NewTableConfiguration object (similar to the pattern for
> > > > BatchWriterConfig), which allows us to be flexible on improving table
> > > > creation options in the future without creating many overloaded
> methods
> > > (as
> > > > the table creation API has been plagued by in the past). The main
> goal
> > of
> > > > the patch is to allow table properties to be set on a table at the
> time
> > > of
> > > > creation, before any tablets are assigned, but it also lays the
> > > foundation
> > > > for future table creation improvements. Creating initial table
> > properties
> > > > was already present in the RPC calls, but not exposed in the API.
> This
> > > can
> > > > support a number of use cases.
> > > >
> > > > Since an objection was raised by Sean Busbey (and a veto expected),
> > I've
> > > > initiated this vote in lieu of applying the patch under lazy
> consensus
> > so
> > > > that any veto votes can be justified and addressed here.
> > > >
> > > > Note: there are a few bugs in the Mock implementation of this that
> I've
> > > > fixed, as well as some minor deprecation warnings and javadoc
> > > improvements
> > > > I'm adding, please apply your vote under the assumption that those
> will
> > > be
> > > > fixed before it will be applied.
> > > >
> > > > Please vote in accordance with the bylaws for consensus voting.
> > > > My vote is +1.
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>

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