On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey <bus...@cloudera.com> 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? > > 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? -> Please address the fact that there is no breakage here... -> 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). -> Another reasonable compromise has also been proposed that seems to address all of your concerns. Please explain why it does not. 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? -> 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? > 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. > > The issue is not moot. As multiple people have emphasized, a veto is the start of dialogue, not the end of it. Addressing these questions/requests pertaining to your veto will help establish consensus moving forward, and provide background for future votes on this (and perhaps other) issues. You also cannot reasonably expect the community to be bound by vetoes which are not defended against when questioned. Leaving questions unanswered in regards to your veto simply because the time has elapsed sets a very bad precedent for how to handle vetoes. > On Mon, Dec 1, 2014 at 1:59 PM, Christopher <ctubb...@apache.org> 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 <ctubb...@apache.org> > wrote: > > > > > On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <bus...@cloudera.com> > > wrote: > > > > > >> Responses to a few things below. > > >> > > >> > > >> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <bfl...@praxiseng.com> > > 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 <bus...@cloudera.com> > > 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 <ctubb...@apache.org> > > wrote: > > >> > > >> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki < > > >> bhava...@clouderagovt.com> > > >> > 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 <ctubb...@apache.org> > > wrote: > > >> > > >> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <bus...@cloudera.com> > > >> wrote: > > >> > > > >> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <ctubb...@apache.org > > > > >> > wrote: > > >> > > > > >> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey < > bus...@cloudera.com > > > > > >> > > 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 >
