Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of josh.elser@gmail.com designates
 209.85.192.46 as permitted sender)
Message-ID: <547E1A3A.6090300@gmail.com>
Date: Tue, 02 Dec 2014 14:59:54 -0500
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [VOTE] ACCUMULO-3176
References: 
 <CAL5zq9bJkdc+DcRAKB7GAE9KyG+wU4zd9YYH7i24bS=HKUcmyw@mail.gmail.com>
 <CAL5zq9aH04Q0EuGN=CzzfECNrcKHX-=+6vW7kRAWFEay5Q=52A@mail.gmail.com>
 <CAL5zq9ZwcQQ7hF4CN61GZZ56CcktswC3ey9XTLWtpfOEKVGdOA@mail.gmail.com>
 <CAGHyZ6JNJ55GPbgFyRnvejhUfcJvaSYGYLzaJ9rdLNOz+x1fWA@mail.gmail.com>
 <CAL5zq9b-ESk5D6e+qHEe6AgkYGoFfDYGa+RFWfDCQGsxLWW4DA@mail.gmail.com>
 <CAGHyZ6+AOx2V2RpC-jnddjH=XNhx9QarXwKEUph+XO_ea1=o-w@mail.gmail.com>
 <2138095271.12369861.1417547265094.JavaMail.zimbra@comcast.net>
 <547E1434.1080001@gmail.com>
 <733708023.12413927.1417549519321.JavaMail.zimbra@comcast.net>
In-Reply-To: <733708023.12413927.1417549519321.JavaMail.zimbra@comcast.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks, Dave. I took his remark in the context of the original veto -- 
both sides have differing opinions, we have clearly hashed this out now.

I assume that Sean is still willing to work through finding something 
amenable to everyone (as he would be obligated to do as long as he 
considers the changeset veto'ed), but we need to change the discussion 
focus onto what needs to change rather than rehashing the same 
disagreement over again.

dlmarion@comcast.net wrote:
> I took Sean's comment (below) to mean the discussion was over. By his comments, I think he intends to stop discussing this sooner rather than later without resolution. I think it's fair to point out that he had an opposite opinion 6 months ago. I wrote it as nicely as possible given my mood about the subject.
>
>
> "While I agree that objections are the start of a conversation, votes are
> meant to be provide closure so the community can move on to other work. I'd
> ask that we try to bring this thread to a close."
>
>
>
>
> ----- Original Message -----
>
> From: "Josh Elser"<josh.elser@gmail.com>
> To: dev@accumulo.apache.org
> Sent: Tuesday, December 2, 2014 2:34:12 PM
> Subject: Re: [VOTE] ACCUMULO-3176
>
> Let's please try to not get snarky here, Dave. We're all trying to have
> a reasonable discussion, get to the real issues, and figure out how we
> can work through them without stomping on anyone. As always, you are
> welcome to fork for you personal reasons -- I don't want to force you
> down that path, but this is going to take some more time to resolve.
>
> Obligatory thank you to Sean for writing up his opinions: it helps us
> all understand what would be acceptable presently for him to retract his
> veto in addition to what he sees as the current issues.
>
> What I took away from his response: we need to (re)visit what 1.7.0 is
> really going to be. Rightfully so, we left 1.7 as a intermediate release
> to let us continue to develop, with the intent to do 2.0.0 as the next
> fancy thing. Assuming that is still the plan (which has not been
> otherwise changed), Sean's objection is reasonable. API changes
> definitely doesn't seem to be in scope for something that was to be a
> very minor "major" release.
>
> That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
> started considering 1.7.0 to be another "normal" major release, rather
> than a "minor" one. If we're all in agreement here, I think it would
> make sense to apply our normal API rules to 1.7.0 and then make sure we
> minimize churn between 1.7.0 and 2.0.0 for any additions.
>
> Sean, is that an acceptable avenue to redirect this discussion? Have I
> missed any other sticking points? That the above wouldn't address?
>
> dlmarion@comcast.net wrote:
>> The impetus for these changes comes from the discussion in ACCUMULO-118. This API change and the issues surrounding the per-table Volume Chooser is a follow-on feature to Multi-Volume support that was added in 1.5. I want/need these changes.
>>
>> In ACCUMULO-2844 you wanted, if not demanded, to make a breaking API change (changing the name of the Master) in the development and all bug fix branches without discussion. Here we have a non-breaking API change in a major release and all of a sudden it's an issue. By that logic, we should scrub 1.7 for all API changes and revert them.
>>
>> At this point I would much rather have these changes committed in 2.0 just so we can stop having this ridiculous discussion. I'm happy to fork Accumulo and backport these fixes to the version I need.
>>
>> ----- Original Message -----
>>
>> From: "Sean Busbey"<busbey@cloudera.com>
>> To: "dev@accumulo apache. org"<dev@accumulo.apache.org>
>> Sent: Tuesday, December 2, 2014 1:14:50 PM
>> Subject: Re: [VOTE] ACCUMULO-3176
>>
>> Responses below. I feel like most of these questions (with the noted
>> exception of details on my issue with one of the late compromise positions)
>> were previously answered, but I've tried to add additional detail below
>> where I may have been unclear in prior exchanges.
>>
>> While I agree that objections are the start of a conversation, votes are
>> meant to be provide closure so the community can move on to other work. I'd
>> ask that we try to bring this thread to a close.
>>
>>
>> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner<keith@deenlo.com>  wrote:
>>
>>> The question I was most curious about was why you are ok w/ making this API
>>> change in 2.0 but not 1.7.0. I do not understand the reasoning behind
>>> this.
>>>
>> As a matter of background, over time I have become more convinced of the
>> need for a stable, coherent API. Too many of the end users I have seen
>> endure substantial work because of our altering of the API. This applies
>> equally for forwards and backwards compatibility. When someone has a
>> requirement to use our software and they find that the particular version
>> they need to integrate with is different than they initially expected, I
>> would like them to not have to endure project delays merely for updating
>> use of our API.
>>
>> For 2.0, we already have broad consensus around improving our API in
>> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
>> better delineation of what is and is not expected to stay constant and
>> because we'll have a better formulation of a lifecycle for Accumulo related
>> resources. In that particular matter, it's the proper lifecycle that I
>> personally find compelling enough to broadly cause a burden. This is
>> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>>
>> So, given that we're going to be asking our users to deal with a headache
>> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
>> minimize asking them to take on dealing with changes in versions prior to
>> that. There may be some future issue that fixes something severe enough to
>> warrant changing my position on the matter. This issue did not.
>>
>> I talked previously about my position on API changes in general in the
>> background info for Josh’s message:
>>
>> http://s.apache.org/HJg
>>
>> and I had meant to cover the "we already agreed to break things in 2.0"
>> side in this admittedly short offer of compromise:
>>
>> http://s.apache.org/imf
>>
>>
>>
>> On Mon, Dec 1, 2014 at 4:25 PM, Christopher<ctubbsii@apache.org>  wrote:
>>
>>> Explicit questions and outstanding requests for clarification since your
>>> last response (see previous emails for details and context):
>>> ->  So, are you arguing for no more API additions until 2.0?
>>>
>> My general preference, as mentioned above and previously in the background
>> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
>> that this stance be taken on as a matter of course through this particular
>> vote.
>>
>> I think any change to our API, prior to 2.0 or after, should be carefully
>> considered. How we plan for users to interact with our software over time
>> matters. Through removals we will be directly impacting the ability of
>> operational users to adopt our newer versions. Through additions we will be
>> impacting how system integrators go about building applications above us.
>> It does neither us nor them any good for our API to change merely because
>> it improves our abstractions or condenses our support footprint.
>>
>> In the consideration of the above and the nice-to-have fixes this
>> particular patch brings, I think it can wait for the API overhaul in 2.0.
>>
>> The same two previous mailings I mentioned above to Keith are where I went
>> through this previously.
>>
>>
>>
>>> ->  Please address the fact that there is no breakage here...
>> ->  Another reasonable compromise has also been proposed that seems to
>>
>> address all of your concerns. Please explain why it does not.
>>
>>
>> I think these are the same question, presuming your "other compromise" is
>> the one of adding the new API and leaving the extant create methods
>> undeprecated. If not, please let me know what other compromise I missed so
>> that I can respond accordingly.
>>
>> I covered the breakage part of this explicitly in my response to Keith's
>> question about which part of the API move I was concerned with:
>>
>> http://s.apache.org/nn5
>>
>> Essentially, moving our table creation API to use a configuration object
>> instead of the myriad of different arguments is a shift in how we expect
>> users to interact with Accumulo. Even if the breakage doesn't happen right
>> now, this change is setting downstream users up for pain when the break
>> happens. To that same end, users attempting to proactively stay up to date
>> on our API will break if they have to move backwards. Yes, this a normal
>> part of API evolution. Yes, users will have to do this at some point. I'm
>> merely stating that we have already reached consensus on that point being
>> 2.0 and we should reserve using up the good will of our end users.
>>
>> Similarly, simply expanding our API to have multiple long term ways of
>> doing table creation isn't tenable. For one, downstream users will ask
>> which method to use. Deprecation is how we normally offer them clear
>> guidance on where the API is going in the future. Without that, we'll just
>> be using some proxy for deprecation (either a javadoc or emails on user@).
>> Additionally, since the version that takes a single configuration object is
>> clearly the most sustainable approach, the other methods are likely to be
>> deprecated and then removed should we end up with additional major versions
>> prior to 2.0.
>>
>> I covered some of this concern in my response to Brian in the first part of
>> my last response:
>>
>> http://s.apache.org/0um
>>
>>
>>
>>> ->  Please explain how you see omitting this API addition is compatible with
>>> [the goal of supporting non-major intermediate releases]. 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).
>>
>> I believe I covered this through a combination of the above explanations to
>> Keith and my response to Brian in the first part of my last response:
>>
>> http://s.apache.org/0um
>>
>> That we are having a 1.7 release at all is a matter of scheduling. There
>> are already too many things different in that development line for us to
>> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
>> done to get that release out. That doesn't mean we should feel free to pack
>> as many breaking changes as we want into the release.
>>
>>
>>
>>> Brian also asked:
>>> ->  I don’t see what breakage users would be required to deal with if the
>>> proposed changes were made. A new method would be added to the API and some
>>> existing methods deprecated (presumably to be removed in 2.0). So how would
>>> this hurt our users?
>>>
>>
>> I think this is covered above. In summary, when we alter our API we need to
>> consider long term impact rather than just the immediate release. We are
>> already going to ask our users to handle major changes in a relatively
>> short time period.
>>
>>
>>
>>> ->  Given that you are ok with with the change in 2.0, it seems that your
>>> objection is not to the content of the change but rather the timing of it.
>>> Given that users aren’t required to use the new API method added by the
>>> change, this objection and the veto seem invalid to me. Am I missing
>>> something?
>>>
>>
>> I believe the rest of this message restates in detail my concerns about our
>> API evolution and specifically why I am on board with the planned breakage
>> in the 2.0 release. Let me know where there are particular gaps so I can
>> help clarify.
>>
>> Please everyone stop this divisive tactic of continuing to claim my veto is
>> invalid. The surface of our API and our impact on downstream users are
>> valid technical considerations. Our bylaws clearly state what is needed for
>> a veto to be sustained and I have already passed that bar. Let’s focus our
>> discussion on the underlying problem rather than technicalities of our
>> governance.
>>
>
>