accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [VOTE] ACCUMULO-3176
Date Wed, 26 Nov 2014 16:57:47 GMT
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

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

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 have offered a reasonable compromise position that addresses both my
concerns while adding the feature you want. Please take it.

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


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