On Tue, Dec 2, 2014 at 1:14 PM, Sean Busbey <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. > 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' core/src/main/java/org/apache/accumulo/core/client 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 >
