On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <bus...@cloudera.com> wrote:
> On Tue, Nov 25, 2014 at 2:23 PM, Christopher <ctubb...@apache.org> wrote: > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <bus...@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 >
