Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
Reply-To: vines@apache.org
In-Reply-To: 
 <CAGHyZ6+qbWEh5Or9VtdU013WQ2rnp2O6Du7mme+=PGV_xdOp6Q@mail.gmail.com>
References: 
 <CADczPYRa1h3jQ+4nDBD10K84H+PeRbnkkqZRbD7EUe0a7S+kXA@mail.gmail.com>
 <CAL5zq9ZL8ns6FhGEr06hFsiJ_wDHqtpaPJEEN5tVeu5cqrp5qg@mail.gmail.com>
 <CAGHyZ6JxX8b1VPCi=if-txTWj=SYyr13iWqK1EkLV8gNzctSbQ@mail.gmail.com>
 <CAGHyZ6LDjO_3MywrzHVVTbSVUUHqkrDBYsgCrQghLnitZ5OAzA@mail.gmail.com>
 <CADczPYTFGo8Q3=zt5GOgh=-0phgFPYrgaM6xP00v64mXr_aa1w@mail.gmail.com>
 <CAGHyZ6+qbWEh5Or9VtdU013WQ2rnp2O6Du7mme+=PGV_xdOp6Q@mail.gmail.com>
From: John Vines <vines@apache.org>
Date: Thu, 31 Oct 2013 16:45:48 -0400
Message-ID: 
 <CADczPYRsjT98H_rQFk0zXGv1YsBWCJc9i5iq1p7vqGP1Mftacw@mail.gmail.com>
Subject: Re: 1.6.0 Feature Freeze
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=089e0160a67645881f04ea0f8bdd

--089e0160a67645881f04ea0f8bdd
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 31, 2013 at 4:39 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Thu, Oct 31, 2013 at 1:35 PM, John Vines <vines@apache.org> wrote:
>
> > >
> >
> > So I am interpreting it as all code modifications must be into the
> codebase
> > or review board by the freeze date. Which could be beneifical, however-
> > 1. What about the case where a patch needs to be modified? What if it's a
> > really minor change vs. a major change? Where's the line?
> >
>
> That's up to the release manager, though they can ask the community for
> feedback. :)
>
> Generally, I think this is a non-issue. review board lets you post updates
> to your patch. If it didn't, feedback would be useless. I don't think we're
> saying you can't update your review board.
>
> So I think it comes down to the feedback itself. if it suggests a change
> that you can incorporate into the existing patch, good to go. if it's
> requires a rewrite, then it sounds more like a -1 and goes to the
> removal-vote process.
>
>
>
> > 2. In the case of features that have multiple subtasks, they have
> > complementing features that  NEED to exist to make the main feature
> > usable/maintainable. What happens if we don't get those in?
> >
>
> That's why we have a call-to-remove part of the vote, right? committer
> votes will determine if a given feature has retained enough to be included.
>
> This is also a big advantage of review-then-commit and iterating within the
> ticket before pushing up. You can have these kind of inclusion
> conversations at a much lower cost when you aren't facing the prospect of
> trudging through a bunch of reverts.
>
> --
> Sean
>


All of your comments make sense to me. Unfortunately we're a bit stuck in
the latter category. Going forward we can make steps as a community to help
prevent it, but that doesn't change this release. And beside issue of
pulling out an incrementally committed feature, pulling out features lends
the potential for a release to be insubstantial.

So for the sake of the 1.6.0 release, what do we think we should do about
the sub-tasks for added/expected features? Particularly ones deemed
requisite for that feature to hit the mainline?

--089e0160a67645881f04ea0f8bdd--