+1 to lazy by-laws.
On Fri, Sep 20, 2013 at 2:40 PM, Christopher <ctubb...@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 <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. > >> > >> > > > >> > >> > > >> > >> > >> > > >> >
