Maybe I misunderstood something in this thread, but 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? > On 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. > > > 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. > > 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 have offered a reasonable compromise position that addresses both my > concerns while adding the feature you want. Please take it. > > 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
