Hi Konstantin, The amendment I've proposed actually leaves the Release Plan in place. In fact, where one could say the current bylaws don't require a Release Plan for every release, this amendment makes clear that it does. It just doesn't have to be voted on.
I would think that a controversial release plan would generate discussion, which would give guidance to the prospective RM about what he or she needs to do in order to achieve enough consensus to pass a Product Release vote. There's no need to vote on intentions, tho. If people don't like the release (as planned and/or as delivered) they can vote down the RC, which is a concrete artifact. I'm not concerned that people won't comment until the RC comes out. Folks around here are pretty free with their opinions :-) And release votes are majority vote, so there are no vetoes, and "submarine" behavior doesn't get rewarded. --Matt On Wed, May 22, 2013 at 11:20 AM, Konstantin Shvachko <shv.had...@gmail.com>wrote: > 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/> >> > >> >> > >> > >
