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 <ke...@deenlo.com> wrote: > On Wed, Sep 18, 2013 at 5:43 PM, Mike Drob <md...@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 <ctubb...@apache.org> wrote: >> >> > +1 >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Wed, Sep 18, 2013 at 10:36 AM, Keith Turner <ke...@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 <md...@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.new...@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 < >> dmi...@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 < >> dlmar...@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:bus...@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. >> > >> > > >> > >> > >> > >> >> > >>
