accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 20:41:45 GMT
On Wed, Dec 3, 2014 at 9:48 AM, Sean Busbey <busbey@cloudera.com> wrote:
> API additions matter here because when a system integrator makes an
> application on top of Accumulo they often start at the latest version they
> can find. Later, they may have a client with a regulatory requirement to
> use an earlier version. Porting backwards is just as hard as porting
> forwards in our code base.

With this logic, code bases would never evolve. I want a dynamically
evolving tool that reacts as quickly as possible to better ideas.
Waiting six months for a release that might be delayed does not make
sense to me; especially for an API addition.

I do not want to deeply consider the needs of system integrators when
thinking about evolution of the code case and feature set. When would
that conversation stop? Should we include Lumify or GeoWave in our
conversations? What about the Accumulo port of Presto? Should we place
some limit on system integrator size - only paying attention when the
integrator is donating resources to the project? Or perhaps if the
integrator has only three clients they are not big enough?

What if Optum or Bloomberg has $50 million invested in using Accumulo.
They aren't an integrator but a direct user. Are their needs less
important? Is there some limit to say which customer is important
enough to halt a feature set?

Mime
View raw message