accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] ACCUMULO-3176
Date Mon, 01 Dec 2014 19:59:03 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message