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: 
 <CADczPYRa1h3jQ+4nDBD10K84H+PeRbnkkqZRbD7EUe0a7S+kXA@mail.gmail.com>
References: 
 <CADczPYRa1h3jQ+4nDBD10K84H+PeRbnkkqZRbD7EUe0a7S+kXA@mail.gmail.com>
Date: Thu, 31 Oct 2013 13:37:22 -0400
Message-ID: 
 <CAL5zq9ZL8ns6FhGEr06hFsiJ_wDHqtpaPJEEN5tVeu5cqrp5qg@mail.gmail.com>
Subject: Re: 1.6.0 Feature Freeze
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: text/plain; charset=UTF-8

I think a week extension would be good for projects that are under
review, but I don't think it should be extended for development on
those features (except to address issues from the review). This would
also encourage people to push something potentially disruptive to
ReviewBoard instead of committing at the last minute and having to
revert it later. That would allow us to review stuff that has been
ready, but not committed because people have been busy finishing other
features for the feature freeze and haven't had time to review it yet.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Oct 31, 2013 at 1:02 PM, John Vines <vines@apache.org> wrote:
> I've been going through the tickets (and hopefully not stepping on too many
> toes) for scoping things into 1.6 as we approach the deadline. However,
> looking through the tickets, there seem to be 4 major tasks that have SOME
> amount of work ahead of them to work in a release. To me, these are:
>
> https://issues.apache.org/jira/browse/ACCUMULO-118 - Multiple HDFS spanning
> https://issues.apache.org/jira/browse/ACCUMULO-1009 - SSL
> https://issues.apache.org/jira/browse/ACCUMULO-1481 - Isolated Root table
> (this may be in conjunction with
> https://issues.apache.org/jira/browse/ACCUMULO-802, I am uncertain of the
> plan of action of 1481)
> https://issues.apache.org/jira/browse/ACCUMULO-1000 - Compare and set
> Mutations
>
> These are all tickets that have some standing work and I think these, plus
> RFile encryption, are the core features for 1.6. I apologize if I
> overlooked any other features in 1.6 in that statement. That said, this is
> a LOT of work for people to have pushed in 36 hours. And pulling these
> features out will A. be a giant PITA and B. Leave us with a very lackluster
> release.
>
>
> So, I am proposing maintaining the feature freeze of Friday at midnight
> that we maintained before, EXCEPT for any thing regarding these 4-5
> features I've enumerated. I think an additional week should be sufficient
> for these features to be in a release worthy state. This also means that
> after the general feature freeze date, all non-critical bugs and additional
> features will be bumped to 1.6.1/1.7.0). Because it is a one week timespan,
> I think we can hold off on creating the branch for 1.6.0-SNAPSHOT, but if
> anyone disagrees a second vote can be put in order by someone who feels
> that way.
>
>
>
> Please vote on providing a delayed feature freeze for ACCUMULO-118,
> ACCUMULO-1009, ACCUMULO-1481, ACCUMULO-802, and ACCUMULO-1000 for Nov 8
> 23:59 PDT for the master branch. Shortly after this time we will branch
> 1.6.0-SNAPSHOT from master and increment the version in master in lieu of
> the original Nov 1 23:59 PDT deadline. For all other features, the original Nov
> 1 23:59 PDT applies. "Feature Freeze" means only bug fixes and
> documentation updates happen after the date, which implies major code additions
> and changes are already in place with appropriate tests.
>
> If a commiter thinks a new feature in 1.6.0-SNAPSHOT is not ready for release,
> they should bring it up on the dev list.  If agreement can not be reached
> on the dev list with 72 hours, then the commiter can call for a vote on
> reverting the feature from 1.6.0-SNAPSHOT.  The vote must pass with majority
> approval[1].  If the vote passes, any commiter can revert the feature from
> 1.6.0-SNAPSHOT.
>
> This vote will remain open for 72 hours and must have consensus approval[2]
> to pass. Because of the conflicting time frames with the feature freeze in
> ~36 hours, the post feature freeze actions of the shall be delayed until
> the end of this vote in the event this vote does not pass. This will not
> change the rules of that feature freeze.
>
>
> [1]:http://www.apache.org/foundation/glossary.html#MajorityApproval
> [2]:http://www.apache.org/foundation/glossary.html#ConsensusApproval