Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - 1.6.0 Feature Freeze


Copy link to this message
-
Re: 1.6.0 Feature Freeze
Josh Elser 2013-10-31, 17:43
I'm fine with the idea of what you're proposing. I'll hold off on an
actual vote until the details are resolved (Christopher's and Sean's
responses)

On 10/31/13, 1:02 PM, John Vines 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
>