accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 25 Nov 2014 21:07:44 GMT
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:
> >
> > > > 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.
>
>
Okay, I thought that might be the case, but since this is the first time
I've seen mentioned a concern about API changes, I wanted to be sure. I
appreciate the clarification.


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


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

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