accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Nolet <cjno...@gmail.com>
Subject Re: [VOTE] ACCUMULO-3176
Date Mon, 01 Dec 2014 20:54:36 GMT
+1 in case it wasn't inferred from my previous comments. As Josh stated,
I'm still confused how the veto still holds technical justification- the
changes being made aren't removing methods from the public API.

On Mon, Dec 1, 2014 at 3:42 PM, Josh Elser <josh.elser@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message