Ok, if no one complains I will phrase the vote to include +1's explicitly cast in the discussion thread. --Matt
On Tue, May 21, 2013 at 6:58 PM, Mattmann, Chris A (398J) < chris.a.mattm...@jpl.nasa.gov> wrote: > Why repeat just tally new ones? > > Sent from my iPhone > > On May 21, 2013, at 6:58 PM, "Matt Foley" <ma...@apache.org> wrote: > > > 13/14 +1's. I think that constitutes consensus. Moving this to a VOTE > > thread. Please repeat your +1s :-) > > Cheers, > > --Matt > > > > > > On Tue, May 21, 2013 at 5:33 PM, Mahadev Konar <maha...@hortonworks.com > >wrote: > > > >> +1. > >> > >> thanks > >> mahadev > >> > >> On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla <ka...@cloudera.com> > >> wrote: > >>> +1 (non-binding) > >>> > >>> > >>> On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey > >>> <jiten...@hortonworks.com>wrote: > >>> > >>>> +1 > >>>> > >>>> > >>>> On Tue, May 21, 2013 at 4:02 PM, Eli Collins <e...@cloudera.com> > wrote: > >>>> > >>>>> +1 thanks Matt. > >>>>> > >>>>> > >>>>> On Tue, May 21, 2013 at 2:10 PM, Matt Foley <ma...@apache.org> > wrote: > >>>>> > >>>>>> Hi all, > >>>>>> This has been a side topic in several email threads recently. > >>>> Currently > >>>>> we > >>>>>> have an ambiguity. We have a tradition in the dev community that > >> any > >>>>>> committer can create a branch, and propose release candidates from > >> it. > >>>>> Yet > >>>>>> the Hadoop bylaws say that releases have to be planned in advance, > >> the > >>>>> plan > >>>>>> needs to be voted on, and presumably can be denied. > >>>>>> > >>>>>> Apache policies (primarily here < > >>>> http://www.apache.org/dev/release.html> > >>>>>> and here <http://www.apache.org/foundation/voting.html>, with > >>>>>> non-normative commentary > >>>>>> here< > >>>> > http://incubator.apache.org/guides/releasemanagement.html#best-practice > >>>>>> ) > >>>>>> are very clear on how Releases have to be approved, and our bylaws > >> are > >>>>>> consistent with those policies. But Apache policies don't say > >> anything > >>>>>> I've found about Release Plans, nor about voting on Release Plans. > >>>>>> > >>>>>> I propose the following change, to remove Release Plan votes, and > >> give > >>>> a > >>>>>> simple definition of Release Manager role. I'm opening discussion > >> with > >>>>>> this proposal, and will put it to a vote if we seem to be getting > >>>>>> consensus. Here's the changes I suggest in the > >>>>>> Bylaws<http://hadoop.apache.org/bylaws.html> > >>>>>> document: > >>>>>> > >>>>>> === > >>>>>> > >>>>>> 1. In the "Decision Making" : "Actions" section of the Bylaws, the > >>>>>> following text is removed: > >>>>>> > >>>>>> ** Release Plan* > >>>>>> > >>>>>> Defines the timetable and actions for a release. The plan also > >>>> nominates > >>>>> a > >>>>>> Release Manager. > >>>>>> > >>>>>> Lazy majority of active committers > >>>>>> > >>>>>> > >>>>>> 2. In the "Roles and Responsibilities" section of the Bylaws, an > >>>>> additional > >>>>>> role is defined: > >>>>>> > >>>>>> ** Release Manager* > >>>>>> > >>>>>> A Release Manager (RM) is a committer who volunteers to produce a > >>>> Release > >>>>>> Candidate according to > >>>>>> HowToRelease<https://wiki.apache.org/hadoop/HowToRelease>. > >>>>>> The RM shall publish a Release Plan on the *common-dev@* list > >> stating > >>>>> the > >>>>>> branch from which they intend to make a Release Candidate, at least > >> one > >>>>>> week before they do so. The RM is responsible for building consensus > >>>>> around > >>>>>> the content of the Release Candidate, in order to achieve a > >> successful > >>>>>> Product Release vote. > >>>>>> > >>>>>> === > >>>>>> > >>>>>> Please share your views. > >>>>>> Best regards, > >>>>>> --Matt (long-time release manager) > >>>> > >>>> > >>>> > >>>> -- > >>>> <http://hortonworks.com/download/> > >> >
