accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 02 Dec 2014 20:07:46 GMT
If it helps, I've just initiated a vote for adopting guidelines for API
changes in 1.x versions to deal with the concerns Sean has raised. If we
can agree on a set of guidelines there, perhaps it might help clarify the
right way to move forward on this issue.

Christopher L Tubbs II

On Tue, Dec 2, 2014 at 2:59 PM, Josh Elser <> wrote:

> 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.
> 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"<>
>> To:
>> 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?
>> 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"<>
>>> To: "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<>  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:
>>> and I had meant to cover the "we already agreed to break things in 2.0"
>>> side in this admittedly short offer of compromise:
>>> On Mon, Dec 1, 2014 at 4:25 PM, Christopher<>  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:
>>> 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:
>>>  ->  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:
>>> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message