Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 206781000F for ; Mon, 1 Dec 2014 19:59:05 +0000 (UTC) Received: (qmail 933 invoked by uid 500); 1 Dec 2014 19:59:04 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 896 invoked by uid 500); 1 Dec 2014 19:59:04 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 885 invoked by uid 99); 1 Dec 2014 19:59:04 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 19:59:04 +0000 Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 157721A0019 for ; Mon, 1 Dec 2014 19:58:45 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so10142125ieb.12 for ; Mon, 01 Dec 2014 11:59:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.51.17.66 with SMTP id gc2mr4387468igd.27.1417463943490; Mon, 01 Dec 2014 11:59:03 -0800 (PST) Received: by 10.64.26.130 with HTTP; Mon, 1 Dec 2014 11:59:03 -0800 (PST) In-Reply-To: References: <5474D5A6.3070909@gmail.com> Date: Mon, 1 Dec 2014 14:59:03 -0500 Message-ID: Subject: Re: [VOTE] ACCUMULO-3176 From: Christopher To: Accumulo Dev List Content-Type: multipart/alternative; boundary=001a1135f3a4d5952005092d0af5 --001a1135f3a4d5952005092d0af5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopher wrote: > On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey wrote= : > >> Responses to a few things below. >> >> >> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss wrote= : >> >> > Aren=E2=80=99t API-breaking changes allowed in 1.7? If this change is = ok for >> 2.0, >> > then what is the technical reason why it is ok for version 2.0 but >> vetoed >> > for version 1.7? >> > >> > > On Nov 25, 2014, at 3:48 PM, Sean Busbey wrote= : >> > > >> > > >> > > How about if we push this change in the API out to the client >> reworking >> > in >> > > 2.0? Everything will break there anyways so users will already have = to >> > deal >> > > with the change. >> > >> >> As I previously mentioned, API breaking changes are allowed on major >> revisions. Currently, 1.7 is a major revision (and I have consistently >> argued for it to remain classified as such). That doesn't mean we >> shouldn't >> consider the cost to end users of making said changes. >> >> There is no way to know that there won't be a 1.8 or later version after >> 1.7 and before 2.0. We already have consensus to do a sweeping overhaul = of >> the API for that later release and have had that consensus for quite som= e >> time. Since users will already have to deal with that breakage in 2.0 I >> don't see this improvement as worth making them deal with changes prior = to >> that. >> >> > So, are you arguing for no more API additions until 2.0? Because, that's > what it sounds like. As is, your general objection to the API seems to be > independent of this change, but reflective of an overall policy for API > additions. Please address why your argument applies to this specific > change, and wouldn't to other API additions. Otherwise, this seems to be = a > case of special pleading. > > Please address the fact that there is no breakage here, and we can ensure > that there won't be any more removal (except in exceptional circumstances= ) > of deprecated APIs until 2.0 to ease changes. (I actually think that woul= d > be a very reasonable policy to adopt today.) In addition, I fully expect > that 2.0 will be fully compatible with 1.7, and will also not introduce a= ny > breakage except removal of things already deprecated in 1.7. If we make > this change without marking the previous createTable methods as deprecate= d, > this new API addition AND the previous createTable API will still be > available in 2.0 (as deprecated), and will not be removed until 3.0. > > You have also previously argued for more intermediate releases between > major releases. Please explain how you see omitting this API addition is > compatible with that goal. Please also explain why, if you consider 1.7 t= o > be a major (expected) release, why such an addition would not be > appropriate, but would be appropriate for a future major release (2.0). > > >> >> On Tue, Nov 25, 2014 at 4:18 PM, Christopher wrote= : >> >> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki < >> bhavanki@clouderagovt.com> >> > wrote: >> > >> > > In my interpretation of Sean's veto, what he says is bad - using the >> ASF >> > > word here - is not that the change leaves the property update >> unsolved. >> > > It's that it changes the API without completely solving it. The >> purpose >> > of >> > > the change is not explicitly to alter the API, but it does cause tha= t >> to >> > > happen, and it is that aspect that is "bad" (with the given >> > justification). >> > > I just want to clarify my reasoning. >> > > >> > > That is my current understanding, as well. Additionally, it seems to >> me >> > that the two things that make it "bad" is that it A) doesn't achieve a= n >> > additional purpose (which can be achieved with additional work), and >> that >> > B) it deprecates existing methods (which can be avoided). Unless there= 's >> > some other reason that makes it a "bad" change, or something else that >> we >> > still need to discuss, I would urge Sean to retract his veto with the >> > proposed compromise to not deprecate and the creation of an independen= t >> > JIRA issue to address the concerns about update race conditions. >> > >> >> Back and forth negotiation to find a solution that addresses both the >> concerns of an objector and the proposer of a change should happen on th= e >> jira and/or reviewboard for that change. They should not happen on a >> formal >> VOTE thread following that objection; they most certainly should not onl= y >> happen after an attempt to use process to ignore the concerns has failed= . >> >> > Nobody is ignoring the concerns raised. We are attempting to resolve thos= e > through reasonable dialogue and are attempting to lobby you to retract yo= ur > veto, after addressing your concerns, in accordance with the section of t= he > bylaws which describes vetoes. This is the appropriate place to do that, > because a consensus vote is not simply a number tallying action, as a > majority vote might be considered to be. > > >> That said, I am generally a proponent of not letting "where discussion >> should happen" get in the way of reaching consensus. However, in this ca= se >> I don't think we have sufficient time to work through the details of why= I >> don't find API sprawl a compelling fix for my concerns. I know I >> definitely >> don't have the spoons for it. >> >> I'm sorry, but if you are unwilling to defend your veto further, I don't > see how you can expect it to be binding. Please address why this change > could not be introduced with the compromise proposed. > > >> I have offered a reasonable compromise position that addresses both my >> concerns while adding the feature you want. Please take it. >> >> Another reasonable compromise has also been proposed that seems to > address all of your concerns. Please explain why it does not. > > I would also like to add that inclusion of this now would greatly help me > add the wiring necessary for the new API. > > >> I don't think I'll have time to be on email again before the vote closes= . >> You may consider my -1 withdrawn if the change is restricted to 2.0 >> >> >> On Tue, Nov 25, 2014 at 3:07 PM, Christopher wrote= : >> >> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey >> wrote: >> > >> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher >> > wrote: >> > > >> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey >> > > wrote: >> > > > >> > > > >> > > > >> > > I understand that the use cases enabled by this patch are sufficient= ly >> > > compelling for you. They are not sufficiently compelling for me, >> hence my >> > > veto. >> > > >> > > >> > I don't know that there is a requirement to make every code addition >> > sufficiently compelling to every developer, in order to include it. If >> that >> > were the case, I don't think many features would have made it in. This >> > seems to be an anti-progress position if we allow it to become the >> norm. It >> > seems to me that there should be compelling reasons to reject a >> > contribution that does not break or affect existing functionality. >> > >> >> This VOTE thread is also not the place to get into a discussion of our >> governance model. However, what you are saying is directly opposed to th= e >> fundamental way code changes work in Apache projects; it's the "Review" >> part of Commit Then Review and Review Then Commit. We use the former >> because we presume that most changes will be compelling. Because every >> part >> of "compelling" and "cost" is hugely subjective we require that vetoes >> come >> with a rationale. >> >> It is indeed very anti-progress. That's one of the overheads of being in= a >> community. It's also why I have previously stated that these change vote= s >> should be Majority Approval instead of Consensus Approval. >> >> > Also, since you can only veto >> > changesets, and not release candidates, I don't see what would stop a >> > release manager from backporting this changeset to 1.7 prior to its >> release >> > if we push it to a 2.0 branch. I don't see why this improvement must b= e >> > postponed. >> >> The thing that would stop them is that we are a community. It would be >> incredibly rude for a release manager to do this after the restriction t= o >> 2.0 was the end compromise reached. We are not in a state of nature and >> the >> bylaws are not our leviathan. We are a group working towards common goal= s. >> >> >> -- >> Sean >> > > --001a1135f3a4d5952005092d0af5--