On Tue, Nov 25, 2014 at 3:34 PM, Bill Havanki <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 >
