accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Initial Release Plan for 2.0.0
Date Sat, 07 Jun 2014 17:17:46 GMT
On Sat, Jun 7, 2014 at 12:52 PM, Sean Busbey <> wrote:

> inline
> On Sat, Jun 7, 2014 at 11:40 AM, Christopher <> wrote:
> > I'd consider the compatibility statement a blocker for the release, but
> not
> > a blocker for the release plan.
> >
> >
> Certainly. I just don't see it listed on the release plan for something
> we'd want done prior to releasing. That's the only reason I mentioned it.

I knew I'd forget something important. :)

> I said 2.2, because the only Hadoop releases prior to that in the 2.x
> > series are alpha/beta releases... and I wouldn't want to have to maintain
> > compatibility with alpha/beta releases. It may be that those would work
> > just fine... I just don't want to make it a goal.
> >
> >
> That sounds reasonable to me. I just want to make sure we discuss it in
> case someone else has a particular need for an earlier compat.

Personally, I think a requirement to use an alpha/beta HDFS is probably a
sufficiently fringe use case to expect those users to consider patching
upstream Accumulo or upgrading to a stable HDFS release, rather than
require our work to hold back to the alpha/beta APIs. However, I don't feel
strongly, and we can easily do testing on 2.0.0 <= HDFS < 2.2.0 also.

> Given our past history of releases, I think Sept 12 would be *way* too
> > optimistic. This timeline is already shorter than the 1.6 one, but I want
> > to be practical. If things go more rapidly than we expect, we can release
> > earlier, but I'd rather not impose an artificial rush on things.
> >
> >
> Didn't 1.6 have a much larger target feature set? I don't recall if a
> formal set of "what do we want in 1.6" plan happened, but IIRC the meeting
> notes from the initial video chat discussion had a fairly extensive list.

It's hard to say which has a larger feature set, since the list for 2.0.0
is not exhaustive. Something that should be understood about the history of
Accumulo development, is that it is far more dynamic than a formulaic
enumeration of features followed by a release of those features. We tend to
identify new needs and opportunities during the active development on the
next major release, and not just up front at the beginning. I know this
isn't necessarily ideal, and we may want to work towards something more
formulaic in the future (I don't think we'll get there overnight), but
that's the reality of the project as it has been and currently is.

To put this in context, the video discussion/meeting notes you're referring
to at the beginning of the 1.6.0 development wasn't a decision about what
features we were including, in the formulaic, up-front feature set sense
(at least, that's not how I saw it). Rather, it was a discussion about what
features each of the people involved wanted to work on and accomplish. It
was not an exhaustive list, and some of the things we discussed didn't get
done. Other contributors, who weren't even in the video discussion
contributed to yet other features. So, there's still many opportunities for
people to pick up existing and neglected tickets, as well as new ones, and
complete them for 2.0.0.

> The obvious blocker is going to be the new API. Probably that work can be
> broken up across multiple people though?

Yes. There's already multiple issues for that, and will almost certainly
include development contributions from multiple developers.

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