accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] ACCUMULO-3176
Date Mon, 01 Dec 2014 20:40:35 GMT
On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey <busbey@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?
>

The question I was most curious about was why you are ok w/ making this API
change in 2.0 but not 1.7.0.  I do not understand the reasoning behind this.


>
> 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.
>

Well shame on me for not voting.  Better late than never.

+1


>
> 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
> > >>
> > >
> > >
> >
>
>
>
> --
> Sean
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message