On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey <[email protected]> wrote:
> I'm not sure what questions weren't previously answered in my explanations, > could you please restate which ever ones you want clarification on? > 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. > > The vote is closed and only has 2 binding +1s. That means it fails under > consensus rules regardless of my veto, so the issue seems moot. > Well shame on me for not voting. Better late than never. +1 > > On Mon, Dec 1, 2014 at 1:59 PM, Christopher <[email protected]> wrote: > > > So, it's been 5 days since last activity here, and there are still some > > questions/requests for response left unanswered regarding the veto. I'd > > really like a response to these questions so we can put this issue to > rest. > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > On Wed, Nov 26, 2014 at 1:21 PM, Christopher <[email protected]> > wrote: > > > > > On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <[email protected]> > > wrote: > > > > > >> Responses to a few things below. > > >> > > >> > > >> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <[email protected]> > > wrote: > > >> > > >> > Aren’t API-breaking changes allowed in 1.7? If this change is ok for > > >> 2.0, > > >> > then what is the technical reason why it is ok for version 2.0 but > > >> vetoed > > >> > for version 1.7? > > >> > > > >> > > On Nov 25, 2014, at 3:48 PM, Sean Busbey <[email protected]> > > wrote: > > >> > > > > >> > > > > >> > > How about if we push this change in the API out to the client > > >> reworking > > >> > in > > >> > > 2.0? Everything will break there anyways so users will already > have > > to > > >> > deal > > >> > > with the change. > > >> > > > >> > > >> As I previously mentioned, API breaking changes are allowed on major > > >> revisions. Currently, 1.7 is a major revision (and I have consistently > > >> argued for it to remain classified as such). That doesn't mean we > > >> shouldn't > > >> consider the cost to end users of making said changes. > > >> > > >> There is no way to know that there won't be a 1.8 or later version > after > > >> 1.7 and before 2.0. We already have consensus to do a sweeping > overhaul > > of > > >> the API for that later release and have had that consensus for quite > > some > > >> time. Since users will already have to deal with that breakage in 2.0 > I > > >> don't see this improvement as worth making them deal with changes > prior > > to > > >> that. > > >> > > >> > > > So, are you arguing for no more API additions until 2.0? Because, > that's > > > what it sounds like. As is, your general objection to the API seems to > be > > > independent of this change, but reflective of an overall policy for API > > > additions. Please address why your argument applies to this specific > > > change, and wouldn't to other API additions. Otherwise, this seems to > be > > a > > > case of special pleading. > > > > > > Please address the fact that there is no breakage here, and we can > ensure > > > that there won't be any more removal (except in exceptional > > circumstances) > > > of deprecated APIs until 2.0 to ease changes. (I actually think that > > would > > > be a very reasonable policy to adopt today.) In addition, I fully > expect > > > that 2.0 will be fully compatible with 1.7, and will also not introduce > > any > > > breakage except removal of things already deprecated in 1.7. If we make > > > this change without marking the previous createTable methods as > > deprecated, > > > this new API addition AND the previous createTable API will still be > > > available in 2.0 (as deprecated), and will not be removed until 3.0. > > > > > > You have also previously argued for more intermediate releases between > > > major releases. Please explain how you see omitting this API addition > is > > > compatible with that goal. 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). > > > > > > > > >> > > >> On Tue, Nov 25, 2014 at 4:18 PM, Christopher <[email protected]> > > wrote: > > >> > > >> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki < > > >> [email protected]> > > >> > wrote: > > >> > > > >> > > In my interpretation of Sean's veto, what he says is bad - using > the > > >> ASF > > >> > > word here - is not that the change leaves the property update > > >> unsolved. > > >> > > It's that it changes the API without completely solving it. The > > >> purpose > > >> > of > > >> > > the change is not explicitly to alter the API, but it does cause > > that > > >> to > > >> > > happen, and it is that aspect that is "bad" (with the given > > >> > justification). > > >> > > I just want to clarify my reasoning. > > >> > > > > >> > > That is my current understanding, as well. Additionally, it seems > to > > >> me > > >> > that the two things that make it "bad" is that it A) doesn't achieve > > an > > >> > additional purpose (which can be achieved with additional work), and > > >> that > > >> > B) it deprecates existing methods (which can be avoided). Unless > > there's > > >> > some other reason that makes it a "bad" change, or something else > that > > >> we > > >> > still need to discuss, I would urge Sean to retract his veto with > the > > >> > proposed compromise to not deprecate and the creation of an > > independent > > >> > JIRA issue to address the concerns about update race conditions. > > >> > > > >> > > >> Back and forth negotiation to find a solution that addresses both the > > >> concerns of an objector and the proposer of a change should happen on > > the > > >> jira and/or reviewboard for that change. They should not happen on a > > >> formal > > >> VOTE thread following that objection; they most certainly should not > > only > > >> happen after an attempt to use process to ignore the concerns has > > failed. > > >> > > >> > > > Nobody is ignoring the concerns raised. We are attempting to resolve > > those > > > through reasonable dialogue and are attempting to lobby you to retract > > your > > > veto, after addressing your concerns, in accordance with the section of > > the > > > bylaws which describes vetoes. This is the appropriate place to do > that, > > > because a consensus vote is not simply a number tallying action, as a > > > majority vote might be considered to be. > > > > > > > > >> That said, I am generally a proponent of not letting "where discussion > > >> should happen" get in the way of reaching consensus. However, in this > > case > > >> I don't think we have sufficient time to work through the details of > > why I > > >> don't find API sprawl a compelling fix for my concerns. I know I > > >> definitely > > >> don't have the spoons for it. > > >> > > >> I'm sorry, but if you are unwilling to defend your veto further, I > don't > > > see how you can expect it to be binding. Please address why this change > > > could not be introduced with the compromise proposed. > > > > > > > > >> I have offered a reasonable compromise position that addresses both my > > >> concerns while adding the feature you want. Please take it. > > >> > > >> Another reasonable compromise has also been proposed that seems to > > > address all of your concerns. Please explain why it does not. > > > > > > I would also like to add that inclusion of this now would greatly help > me > > > add the wiring necessary for the new API. > > > > > > > > >> I don't think I'll have time to be on email again before the vote > > closes. > > >> You may consider my -1 withdrawn if the change is restricted to 2.0 > > >> > > >> > > >> On Tue, Nov 25, 2014 at 3:07 PM, Christopher <[email protected]> > > wrote: > > >> > > >> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <[email protected]> > > >> wrote: > > >> > > > >> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <[email protected] > > > > >> > wrote: > > >> > > > > >> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey < > [email protected] > > > > > >> > > wrote: > > >> > > > > > >> > > > > > >> > > > > > >> > > I understand that the use cases enabled by this patch are > > sufficiently > > >> > > compelling for you. They are not sufficiently compelling for me, > > >> hence my > > >> > > veto. > > >> > > > > >> > > > > >> > I don't know that there is a requirement to make every code addition > > >> > sufficiently compelling to every developer, in order to include it. > If > > >> that > > >> > were the case, I don't think many features would have made it in. > This > > >> > seems to be an anti-progress position if we allow it to become the > > >> norm. It > > >> > seems to me that there should be compelling reasons to reject a > > >> > contribution that does not break or affect existing functionality. > > >> > > > >> > > >> This VOTE thread is also not the place to get into a discussion of our > > >> governance model. However, what you are saying is directly opposed to > > the > > >> fundamental way code changes work in Apache projects; it's the > "Review" > > >> part of Commit Then Review and Review Then Commit. We use the former > > >> because we presume that most changes will be compelling. Because every > > >> part > > >> of "compelling" and "cost" is hugely subjective we require that vetoes > > >> come > > >> with a rationale. > > >> > > >> It is indeed very anti-progress. That's one of the overheads of being > > in a > > >> community. It's also why I have previously stated that these change > > votes > > >> should be Majority Approval instead of Consensus Approval. > > >> > > >> > Also, since you can only veto > > >> > changesets, and not release candidates, I don't see what would stop > a > > >> > release manager from backporting this changeset to 1.7 prior to its > > >> release > > >> > if we push it to a 2.0 branch. I don't see why this improvement must > > be > > >> > postponed. > > >> > > >> The thing that would stop them is that we are a community. It would be > > >> incredibly rude for a release manager to do this after the restriction > > to > > >> 2.0 was the end compromise reached. We are not in a state of nature > and > > >> the > > >> bylaws are not our leviathan. We are a group working towards common > > goals. > > >> > > >> > > >> -- > > >> Sean > > >> > > > > > > > > > > > > -- > Sean >
