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 http://gravatar.com/ctubbsii On Tue, Dec 2, 2014 at 2:59 PM, Josh Elser <josh.el...@gmail.com> 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. > > > dlmar...@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.el...@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? >> >> dlmar...@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"<bus...@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<ke...@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<ctubb...@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. >>> >>> >> >>
