Couldn't reply yesterday. I will try to argue this is a useful action and that keeping it in Bylaws does not change regular release process.
- Bylaws do not require to vote on every release plan. If nobody complains then it is a routine process of building a RC and voting on it. - It is useful to vote on a release plan when there are concerns about how that particular plan effects the evolution of the project. It is better to reach consensus on intentions rather than disagree when the release is ready. This is also a way to unite the community to work in common direction and avoid fragmentation of the project. Otherwise people who do not support the direction keep developing their own branches and forks. I like the second change defining the role of RM. Very well formulated, thanks Matt. --Konstantin On Tue, May 21, 2013 at 7:01 PM, Matt Foley <ma...@apache.org> wrote: > 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/> > > >> > > >
