accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 02 Dec 2014 19:32:27 GMT
On Tue, Dec 2, 2014 at 1:14 PM, Sean Busbey <> wrote:

> 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
> > 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.

You have raised some good points.  I think considering 1.7.0 API changes
w.r.t 2.0 is a good thing to consider and discuss.   Drawing a line in the
sand w/ a particular 1.7.0 API change doesn't really get us anywhere since
there are already a few API changes in the 1.7 branch (what the heck is
ACCUMULO-9998?)   Any strategy for this will need to be agreed upon by the
community and consider the existing API changes.  A more positive way to do
this would be to discuss a plan, write a proposal, and vote on it.

$ git log --oneline -G 'ince\s+1.7.0'
e0fe2ae ACCUMULO-1957 test/whitespace cleanup
c2d95a1 ACCUMULO-1957 implement per-session Durability
f0a6718 ACCUMULO-9998 add waitForBalance API call
baa7a4f ACCUMULO-2583 First stab at setting up the actual wire transfer to
the replication peer

Also I have had ACCUMULO-1798 up for review for a while and have not hear
any complaints about API changes.   I wanted to finish ACCUMULO-3134 and
put it up for review before committing 1798.

> --
> Sean

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