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 2E737102A8 for ; Mon, 1 Dec 2014 20:55:22 +0000 (UTC) Received: (qmail 44108 invoked by uid 500); 1 Dec 2014 20:55:22 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 44066 invoked by uid 500); 1 Dec 2014 20:55:22 -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 44052 invoked by uid 99); 1 Dec 2014 20:55:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 20:55:21 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cjnolet@gmail.com designates 209.85.213.180 as permitted sender) Received: from [209.85.213.180] (HELO mail-ig0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 20:55:17 +0000 Received: by mail-ig0-f180.google.com with SMTP id h15so9626444igd.7 for ; Mon, 01 Dec 2014 12:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=q8arOPXF3kk1WaqtclAvFL9hESVAtLjxhjX2xnwDoc8=; b=VZCBDs53IAtqKdNoqULTCU05jmVZE+LWhP/+VbbEy3dFRwS2aV6vR9a4POxJUoaAYi k4iBk60GPEvw2ThAXhPUvdoetf/9h/21LMG2/8a48aDS1LAm5Zg0IGKgFDua3EGfVcYV /jSHuYLGsxW/XV8h7z8osMaHGUENhmlEbZod1OdCr5K9Y0i7uWGVE9wxdBCFTqVYeMw+ dmrDGXK60KxoN70vSzbcGeUHety+P2Eom8sbM3018YteA9EXkx+1/pjqvqb2YHYOhfVZ yH8mDRtC59S2NEDhyF57oegJkepobr8XjVIlshbA6YQHhQs4efdWJLGlbInCZaV2KCbn f2kw== X-Received: by 10.50.93.6 with SMTP id cq6mr48594311igb.7.1417467296995; Mon, 01 Dec 2014 12:54:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.65.14.135 with HTTP; Mon, 1 Dec 2014 12:54:36 -0800 (PST) In-Reply-To: <547CD29A.4090807@gmail.com> References: <5474D5A6.3070909@gmail.com> <547CD29A.4090807@gmail.com> From: Corey Nolet Date: Mon, 1 Dec 2014 15:54:36 -0500 Message-ID: Subject: Re: [VOTE] ACCUMULO-3176 To: "dev@accumulo.apache.org" Content-Type: multipart/alternative; boundary=047d7b3a8c6ab7e11705092dd2d1 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b3a8c6ab7e11705092dd2d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 in case it wasn't inferred from my previous comments. As Josh stated, I'm still confused how the veto still holds technical justification- the changes being made aren't removing methods from the public API. On Mon, Dec 1, 2014 at 3:42 PM, Josh Elser wrote: > I still don't understand what could even be changed to help you retract > your veto. > > A number of people here have made suggestions about altering the changes > to the public API WRT to the major version. I think Brian was the most > recent, but I recall asking the same question on the original JIRA issue > too. > > > Sean Busbey wrote: > >> I'm not sure what questions weren't previously answered in my >> explanations, >> could you please restate which ever ones you want clarification on? >> >> The vote is closed and only has 2 binding +1s. That means it fails under >> consensus rules regardless of my veto, so the issue seems moot. >> >> On Mon, Dec 1, 2014 at 1:59 PM, Christopher wrote: >> >> 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 consistentl= y >>>>> 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 overha= ul >>>>> >>>> of >>> >>>> the API for that later release and have had that consensus for quite >>>>> >>>> some >>> >>>> 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 pri= or >>>>> >>>> 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 AP= I >>>> 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 >>>> >>> would >>> >>>> be a very reasonable policy to adopt today.) In addition, I fully expe= ct >>>> that 2.0 will be fully compatible with 1.7, and will also not introduc= e >>>> >>> any >>> >>>> breakage except removal of things already deprecated in 1.7. If we mak= e >>>> this change without marking the previous createTable methods as >>>> >>> deprecated, >>> >>>> 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 >>>> >>> to >>> >>>> 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 th= e >>>>>>> >>>>>> 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 >>>>>>> >>>>>> that >>> >>>> 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 t= o >>>>>>> >>>>>> me >>>>> >>>>>> that the two things that make it "bad" is that it A) doesn't achieve >>>>>> >>>>> an >>> >>>> 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 th= e >>>>>> proposed compromise to not deprecate and the creation of an >>>>>> >>>>> independent >>> >>>> JIRA issue to address the concerns about update race conditions. >>>>>> >>>>>> Back and forth negotiation to find a solution that addresses both t= he >>>>> concerns of an objector and the proposer of a change should happen on >>>>> >>>> the >>> >>>> jira and/or reviewboard for that change. They should not happen on a >>>>> formal >>>>> VOTE thread following that objection; they most certainly should not >>>>> >>>> only >>> >>>> happen after an attempt to use process to ignore the concerns has >>>>> >>>> failed. >>> >>>> >>>>> Nobody is ignoring the concerns raised. We are attempting to resolve >>>> >>> those >>> >>>> through reasonable dialogue and are attempting to lobby you to retract >>>> >>> your >>> >>>> veto, after addressing your concerns, in accordance with the section o= f >>>> >>> the >>> >>>> bylaws which describes vetoes. This is the appropriate place to do tha= t, >>>> 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 discussio= n >>>>> should happen" get in the way of reaching consensus. However, in this >>>>> >>>> case >>> >>>> 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 chang= e >>>> could not be introduced with the compromise proposed. >>>> >>>> >>>> I have offered a reasonable compromise position that addresses both m= y >>>>> 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 >>>>>>> >>>>>> sufficiently >>> >>>> 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 additi= on >>>>>> 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. Th= is >>>>>> 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 >>>>> >>>> the >>> >>>> 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 ever= y >>>>> part >>>>> of "compelling" and "cost" is hugely subjective we require that vetoe= s >>>>> 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 >>>>> >>>> votes >>> >>>> 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 >>>>>> >>>>> be >>> >>>> postponed. >>>>>> >>>>> The thing that would stop them is that we are a community. It would b= e >>>>> incredibly rude for a release manager to do this after the restrictio= n >>>>> >>>> to >>> >>>> 2.0 was the end compromise reached. We are not in a state of nature an= d >>>>> the >>>>> bylaws are not our leviathan. We are a group working towards common >>>>> >>>> goals. >>> >>>> >>>>> -- >>>>> Sean >>>>> >>>>> >>>> >> >> >> --047d7b3a8c6ab7e11705092dd2d1--