accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] ACCUMULO-3176
Date Mon, 01 Dec 2014 20:42:02 GMT
I still don't understand what could even be changed to help you retract 
your veto.

A number of people here have made suggestions about altering the changes 
to the public API WRT to the major version. I think Brian was the most 
recent, but I recall asking the same question on the original JIRA issue 
too.

Sean Busbey 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 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.
>
> On Mon, Dec 1, 2014 at 1:59 PM, Christopher<ctubbsii@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<ctubbsii@apache.org>  wrote:
>>
>>> On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey<busbey@cloudera.com>
>> wrote:
>>>> Responses to a few things below.
>>>>
>>>>
>>>> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss<bfloss@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<busbey@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<ctubbsii@apache.org>
>> wrote:
>>>>> On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki<
>>>> bhavanki@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<ctubbsii@apache.org>
>> wrote:
>>>>> On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey<busbey@cloudera.com>
>>>> wrote:
>>>>>> On Tue, Nov 25, 2014 at 2:23 PM, Christopher<ctubbsii@apache.org>
>>>>> wrote:
>>>>>>> On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey<busbey@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
>>>>
>>>
>
>
>

Mime
View raw message