Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of mdrob@mdrob.com designates
 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAL5zq9YKMLk0jTyBa15LqmVWU0JD0dAPZhR0kJJaQ2bVJOV-EQ@mail.gmail.com>
References: 
 <CAGHyZ6KKj8HLXRc4TrY5jB1Ma8OPfqcprYv8COZ5K=NEX6JrtQ@mail.gmail.com>
	<008d01ce7e7f$b7e270e0$27a752a0$@comcast.net>
	<CANndRmKmzwNpb19Y67U17S1PVEb5iaOrscqTjL1hCCH-Gk3WHA@mail.gmail.com>
	<CADxc9BnVvTKkiVG0cnPJn_ZAg9ibj1Y0jNER3tKn+ATQhA1Oog@mail.gmail.com>
	<CAJRvFdqDV_NWedZH-FX+9tpmrCDu0cf=7QWa0ibJ2SKvKskj2Q@mail.gmail.com>
	<CAGUtCHrV3hFzf9J=bLT+4VKRyy_-vo1cQawD14SGzyCbq4arag@mail.gmail.com>
	<CAL5zq9YEHgmCnMMTR7iPbkCSv_0dRHkqzKrT-c7h2qPynzhXbw@mail.gmail.com>
	<CAJRvFdqfQb9pWM0AtueU8V+n+sOTGtcB88fRkwLBXLdvLNF6ow@mail.gmail.com>
	<CAGUtCHqNZC38diDoq43+186hEXjWnFFoPO_7ZSuSWbPzssQabA@mail.gmail.com>
	<CAL5zq9YKMLk0jTyBa15LqmVWU0JD0dAPZhR0kJJaQ2bVJOV-EQ@mail.gmail.com>
Date: Fri, 20 Sep 2013 18:17:03 -0400
Message-ID: 
 <CAJRvFdo_EMKDBpUbyWyQeCBYfqpy1mKN=GH59=Mz3-WVZ6g5Og@mail.gmail.com>
Subject: Re: Schedule for 1.6.0 release?
From: Mike Drob <mdrob@mdrob.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=20cf30781092b85c3604e6d80727

--20cf30781092b85c3604e6d80727
Content-Type: text/plain; charset=ISO-8859-1

+1 to lazy by-laws.


On Fri, Sep 20, 2013 at 2:40 PM, Christopher <ctubbsii@apache.org> wrote:

> Seems reasonable. Some of this should probably be in the
> (non-existent) bylaws. Since we've not really made it a point to vote
> on creation/amendment of bylaws, you could sneak in a paragraph that
> says acceptance of this proposal for the 1.6.0 release process will
> constitute agreement that these rules should be used to
> initialize/amend the bylaws.
>
> In essence, by doing that, we'd be lazily constructing the bylaws from
> an accepted precedent. In the absence of votes that only amend bylaws
> (outside of something specific to a release), this might be a good way
> to go, so we don't have to suggest this process for every such vote.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Sep 20, 2013 at 1:57 PM, Keith Turner <keith@deenlo.com> wrote:
> > On Wed, Sep 18, 2013 at 5:43 PM, Mike Drob <mdrob@mdrob.com> 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 <ctubbsii@apache.org>
> wrote:
> >>
> >> > +1
> >> >
> >> > --
> >> > Christopher L Tubbs II
> >> > http://gravatar.com/ctubbsii
> >> >
> >> >
> >> > On Wed, Sep 18, 2013 at 10:36 AM, Keith Turner <keith@deenlo.com>
> 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 <mdrob@mdrob.com> 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 <
> eric.newton@gmail.com>
> >> > >> 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 <
> >> dminer@clearedgeit.com
> >> > >> > >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
> >> > for
> >> > >> > R&D
> >> > >> > > type projects. We have accumulo on it right now and is
> typically
> >> > doing
> >> > >> > > something hadoop related. If there is a need to do testing of
> >> > accumulo
> >> > >> > > release on bare metal with respectable equipment, let me know
> how
> >> we
> >> > >> > might
> >> > >> > > be able to contribute.
> >> > >> > >
> >> > >> > > -Don
> >> > >> > >
> >> > >> > >
> >> > >> > > On Thu, Jul 11, 2013 at 5:43 PM, Dave Marion <
> >> dlmarion@comcast.net>
> >> > >> > wrote:
> >> > >> > >
> >> > >> > > > Historically, how long has it taken to complete testing of
> >> release
> >> > >> > > > candidates? Subtract that from 1 November and that should be
> the
> >> > >> target
> >> > >> > > > date. Based on 1.5.0, that means feature complete is
> tomorrow,
> >> > right?
> >> > >> > :-)
> >> > >> > > >
> >> > >> > > > -----Original Message-----
> >> > >> > > > From: Sean Busbey [mailto:busbey@cloudera.com]
> >> > >> > > > Sent: Thursday, July 11, 2013 5:17 PM
> >> > >> > > > To: dev@accumulo.apache.org
> >> > >> > > > Subject: Schedule for 1.6.0 release?
> >> > >> > > >
> >> > >> > > > One of the action items out of the 1.6.0 discussion[1] was
> that
> >> > we'd
> >> > >> > use
> >> > >> > > > the list to decide on a target release date, feature set, and
> >> > >> > incremental
> >> > >> > > > milestones for Accumulo 1.6.0.
> >> > >> > > >
> >> > >> > > > I know the initial plan was to aim for November, and right
> now
> >> > Jira
> >> > >> > says
> >> > >> > > > as much[2].
> >> > >> > > >
> >> > >> > > > That's only ~4 months away, so we should lay out some plans.
> >> When
> >> > do
> >> > >> we
> >> > >> > > > need to target feature complete to meet that goal? When does
> >> code
> >> > >> > freeze
> >> > >> > > > need to happen?
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > [1]:
> >> > >> > > >
> >> > >> > > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> https://docs.google.com/a/cloudera.com/document/d/1FkP2dDE4zzH1ou89_-qpW6-7dtBj9XdMRGjFnnLGrTI/edit
> >> > >> > > > [2]:
> >> > >> > >
> >> > https://issues.apache.org/jira/browse/ACCUMULO/fixforversion/12322468
> >> > >> > > >
> >> > >> > > > --
> >> > >> > > > Sean
> >> > >> > > >
> >> > >> > > >
> >> > >> > >
> >> > >> > >
> >> > >> > > --
> >> > >> > > *
> >> > >> > > *Donald Miner
> >> > >> > > Chief Technology Officer
> >> > >> > > ClearEdge IT Solutions, LLC
> >> > >> > > Cell: 443 799 7807
> >> > >> > > www.clearedgeit.com
> >> > >> > >
> >> > >> > > --
> >> > >> > >  This communication is the property of ClearEdge IT Solutions,
> LLC
> >> > and
> >> > >> > may
> >> > >> > > contain confidential and/or privileged information. Any review,
> >> > >> > > retransmissions, dissemination or other use of or taking of any
> >> > action
> >> > >> in
> >> > >> > > reliance upon this information by persons or entities other
> than
> >> the
> >> > >> > > intended recipient is prohibited. If you receive this
> >> communication
> >> > in
> >> > >> > > error, please immediately notify the sender and destroy all
> copies
> >> > of
> >> > >> the
> >> > >> > > communication and any attachments.
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
>

--20cf30781092b85c3604e6d80727--