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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > >> On Sat, Jun 7, 2014 at 12:52 PM, Sean Busbey <[email protected]> > wrote: > >> > >>> inline > >>> > >>> > >>> On Sat, Jun 7, 2014 at 11:40 AM, Christopher <[email protected]> > >>> 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. > >> > > > > >
