accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [VOTE] ACCUMULO-3176
Date Wed, 26 Nov 2014 18:21:41 GMT
On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <> wrote:

> Responses to a few things below.
> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <> 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 <> 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 <> wrote:
> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki <
> >
> > wrote:
> >
> > > In my interpretation of Sean's veto, what he says is bad - using the
> > > 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 <> wrote:
> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <>
> wrote:
> >
> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <>
> > wrote:
> > >
> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <>
> > > 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

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