accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: contrib vs. pushed to other projects
Date Mon, 21 Oct 2013 19:27:44 GMT
On Mon, Oct 21, 2013 at 2:05 PM, Christopher <ctubbsii@apache.org> wrote:

> I think the answer to where things should go depends on two main factors:
>
> 1) Which project(s) does it benefit the most? (does it benefit
> Accumulo users more to have another way to access Accumulo, or does it
> benefit Hive users more to have another database to query from?), and
> 2) Who is going to be responsible for maintaining it?
>
> The first question is probably a very subjective one, so I expect the
> second to play a bigger role. Perhaps the discussion should involve
> both communities to consolidate potentially multiple efforts?
>

I think the second question also comes down to community-specific
subjectivity. For some projects, being in core doesn't imply a different
level of maintenance than being in contrib or being in an outside repo (see
the discussion from this summer around Trevni in Hive) -- if no one uses
something it doesn't get maintained. If that happens long enough, it gets
cut. I don't think we should use that lack of maintenance assurance to mean
that we keep things in Accumulo just because we care about them being
maintained.

I tend to favor Jon's reasoning[1], which mostly focuses on which API is
more likely to change in a way that requires maintenance. In the case of
things like Flume, Hive, or Pig, I think the level of familiarity needed to
maintain an integration point requires more knowledge of the non-Accumulo
side.

If the answer is that it's all case-by-case, then I can just put wording to
that end in the contrib document. I just want to make sure people have some
idea of our reasoning as a project without reading our mail archive or
jiras.

[1]:
http://mail-archives.apache.org/mod_mbox/accumulo-dev/201307.mbox/%3CCAAha9a23xdnJOQyZBT7SOfDtb-Eg2Y2vUJ%2BVH3Eh3AA-rF0sbQ%40mail.gmail.com%3E

-- 
Sean

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