accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <billie.rina...@gmail.com>
Subject Re: Initial Release Plan for 2.0.0
Date Fri, 03 Oct 2014 20:54:45 GMT
I'll have a patch up soon for ACCUMULO-898.  I'd like to get that into
1.7.0.  I was hoping we'd have ACCUMULO-1817 done for 1.7.0, but haven't
had a chance to start working on it yet.

On Fri, Oct 3, 2014 at 1:43 PM, Christopher <ctubbsii@apache.org> wrote:

> Reviving this old thread. 1.7.0 has made significant progress since last
> discussed, but some stuff (like the API) is not ready for a 2.0 bump. I
> think a 1.7.0 release would be warranted. I would, however, like to drop
> support for Hadoop 1 in 1.7.0, if all are on board with that.
>
> The initial release plan needs to be modified, because the proposed Oct 1.
> date has passed. Anybody want to suggest another date? Or suggest
> outstanding issues that they really want to finish up before freezing?
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Jun 19, 2014 at 12:37 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > Since there's not been any further activity on this thread, I'm going to
> > assume there's no issue bumping the version in JIRA to 2.0.0 instead of
> > 1.7.0 and in git master branch.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Sat, Jun 7, 2014 at 1:17 PM, Christopher <ctubbsii@apache.org> wrote:
> >
> >> On Sat, Jun 7, 2014 at 12:52 PM, Sean Busbey <busbey@cloudera.com>
> wrote:
> >>
> >>> inline
> >>>
> >>>
> >>> On Sat, Jun 7, 2014 at 11:40 AM, Christopher <ctubbsii@apache.org>
> >>> 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.
> >>
> >
> >
>

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