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 Tue, 25 Nov 2014 20:42:29 GMT
On Tue, Nov 25, 2014 at 2:23 PM, Christopher <> wrote:

> On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <> wrote:
> > > altering the public API (as a standalone change)
> >
> > I am very conservative about changes to our public API. I have had to
> write
> > code that works across Accumulo versions and even when only working with
> > the public API is it painful on almost every release. I have also seen
> > plenty of cases where deployments of Accumulo lag behind version changes
> > because of this same issue.
> >
> >
> This seems to be a new objection, and independent of your previous veto. Is
> that the case?

I have always stated the same veto for this issue. I am merely providing
the background to my reasoning that Josh requested.

> In general, for me to be positive on an API change there needs to be a
> > compelling improvement or a correctness issue. For me, that correctness
> > issue is the race condition on property updates you mention.
> >
> >
> The use cases described are sufficiently compelling for me. The issue you
> are concerned about for race condition on updates would be a compelling
> change also, which would be worth consideration if somebody were to provide
> a patch to address that. This is not that patch.
I understand that the use cases enabled by this patch are sufficiently
compelling for you. They are not sufficiently compelling for me, hence my

The one use case this provides some succor to that I have found compelling
is the race condition on setting properties that Josh brought up. Since he
asked for more detail about my reasoning around my objection *specifically
in regards to how this patch helps in that use case* I am providing more
detail about why I don't think that partial relief is enough.


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