accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] ACCUMULO-3176
Date Wed, 26 Nov 2014 20:24:59 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 willingness of Sean to withdraw the veto for the change in version 2.0
instead of an earlier version, seems to me to be an indicator that the
objection is not technical in 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.
> - 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.
>
> To be clear, the admission made by me (and others) is that the "general
problem" which isn't solved is a separate issue, and has nothing to do with
the change proposed.


> 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.
>
> I cannot object to your determination (since it only takes one to deem a
veto valid), but I would like to state for the record that I feel that the
fact it does not pertain to the change is precisely the kind of reasoning
that would justify it to be invalid, since relevance seems to be a
prerequisite for validity. So, I do question your reasoning here (if you
could expand on this part, I'd appreciate it). I agree that a change could
be vetoed for doing those things you mentioned (though I don't think a veto
would be a necessary measure for those cases). However, we've already
discussed the fact that this does not impact any other features of this
nature.


> 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