Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAL5zq9bPaWd2ovPOyj0L090hfaxV4TXFtckcCs4co=qCUDxXvw@mail.gmail.com>
References: 
 <CAL5zq9Y=1CVpNoOJfO1MDC9sb8ZvksU9h=m02-eoveWiDmomrw@mail.gmail.com>
	<CAD-fFUKAeGb07mZkaPW6m-rdQj_ntKXSag_YoRoaFa0SrLOD2A@mail.gmail.com>
	<CAGHyZ6JgCkePDzv9-gc_eNAgOQuroFTDdWdoCCwgp_Ujo6SrRA@mail.gmail.com>
	<CAL5zq9a06YDpdVspgNgSjqfC5Wb_amh5GD2W6nrnc5u8z-HM5Q@mail.gmail.com>
	<CAGHyZ6JoK2D_GhKixhZJ9mR1D8NSC6SXS8ZZsLC0rSng78jcxw@mail.gmail.com>
	<CAL5zq9aztQYbVNgai37REc2ezjh6N9d-bPAnQ22beBDFTRXgEA@mail.gmail.com>
	<CAL5zq9bPaWd2ovPOyj0L090hfaxV4TXFtckcCs4co=qCUDxXvw@mail.gmail.com>
Date: Fri, 3 Oct 2014 16:43:06 -0400
Message-ID: 
 <CAL5zq9aC35Hq2Ei_y0xN73dHcuVw0P_DMSAOTxLWUNbkJ7+DRw@mail.gmail.com>
Subject: Re: Initial Release Plan for 2.0.0
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=089e0102d912baa0e205048ac74b

--089e0102d912baa0e205048ac74b
Content-Type: text/plain; charset=UTF-8

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.
>>
>
>

--089e0102d912baa0e205048ac74b--