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

Switch to Threaded View
Accumulo, mail # dev - Schedule for 1.6.0 release?


Copy link to this message
-
Re: Schedule for 1.6.0 release?
Keith Turner 2013-09-20, 17:57
On Wed, Sep 18, 2013 at 5:43 PM, Mike Drob <[EMAIL PROTECTED]> wrote:

> +1 with reservations.
>
> 1.5.0 initially planned for an end-of-year release, but that ended up
> slipping much later. I'd like us to learn from that experience and come
> down much more strictly on the feature freeze this time.
>

One thing I learned from 1.5.0 is we need a conflict resolution process we
agree on in place before the disagreement occurs.  With this in mind I
would like to propose the following feature freeze vote text.  Just putting
up for discussion before we actually vote on it.  I am putting together
peoples comments on this thread and adding something about conflict
resolution.  I just made this up which is why I am posting it for review.
 For Apahce it seems like any veto could prevent a commit from being
accepted http://httpd.apache.org/dev/guidelines.html.  What I proposed
requires more than one persons objection to revert a feature.  I am still
thinking through the implications of this.

------

Subject : [VOTE] 1.6.0 Feature freeze.

Please vote on a feature freeze date of Nov 1 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.  "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.

[1]:http://www.apache.org/foundation/glossary.html#MajorityApproval
[2]:http://www.apache.org/foundation/glossary.html#ConsensusApproval

-----

>
> On Wed, Sep 18, 2013 at 2:14 PM, Christopher <[EMAIL PROTECTED]> wrote:
>
> > +1
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Wed, Sep 18, 2013 at 10:36 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
> > > We do need to get this settled.  What about end of year target for
> > release
> > > date and feature freeze date at end of Oct?
> > >
> > >
> > > On Tue, Aug 27, 2013 at 4:26 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
> > >
> > >> I wanted to revive this conversation, since fall is fast approaching.
> > One
> > >> reasonable target for a release date might be to try and get something
> > done
> > >> before Hadoop World/Strata NY, which is the last week of October. That
> > is a
> > >> bit sooner than initially planned, but would be a great bit of PR if
> it
> > >> were possible. Regardless, we need to seriously think about a feature
> > >> freeze date and get that agreed upon.
> > >>
> > >> Mike
> > >>
> > >>
> > >> On Fri, Jul 12, 2013 at 2:14 PM, Eric Newton <[EMAIL PROTECTED]>
> > >> wrote:
> > >>
> > >> > Absolutely this would be helpful!
> > >> >
> > >> > I have access to a 10-node cluster, and regularly run the continuous
> > >> ingest
> > >> > test, and the random walk tests for long periods (24-48 hours) prior
> > to
> > >> > release.  Running these sooner can shorten the release cycle quite a
> > bit.
> > >> >
> > >> > If anyone has access to a medium-sized cluster (say, 100-500 nodes)
> > that
> > >> > can be used for scale testing, even if only for a short period, or
> > shared
> > >> > with other users, that would be helpful, too.
> > >> >
> > >> > -Eric
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jul 12, 2013 at 2:06 PM, Donald Miner <
> [EMAIL PROTECTED]
> > >> > >wrote:
> > >> >
> > >> > > I've talked to a couple of people about this in person, but
> figured
> > I'd
> > >> > put
> > >> > > it out here.
> > >> > >
> > >> > > I have access to a 16 node cluster in my lab that we typically use