Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - [PROPOSAL] change in bylaws to remove Release Plan vote


Copy link to this message
-
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
Matt Foley 2013-05-22, 19:39
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
<[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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) <
>> [EMAIL PROTECTED]> wrote:
>>
>> > Why repeat just tally new ones?
>> >
>> > Sent from my iPhone
>> >
>> > On May 21, 2013, at 6:58 PM, "Matt Foley" <[EMAIL PROTECTED]> 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 <
>> [EMAIL PROTECTED]
>> > >wrote:
>> > >
>> > >> +1.
>> > >>
>> > >> thanks
>> > >> mahadev
>> > >>
>> > >> On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla <
>> [EMAIL PROTECTED]>
>> > >> wrote:
>> > >>> +1 (non-binding)
>> > >>>
>> > >>>
>> > >>> On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey
>> > >>> <[EMAIL PROTECTED]>wrote:
>> > >>>
>> > >>>> +1
>> > >>>>
>> > >>>>
>> > >>>> On Tue, May 21, 2013 at 4:02 PM, Eli Collins <[EMAIL PROTECTED]>
>> > wrote:
>> > >>>>
>> > >>>>> +1  thanks Matt.
>> > >>>>>
>> > >>>>>
>> > >>>>> On Tue, May 21, 2013 at 2:10 PM, Matt Foley <[EMAIL PROTECTED]>
>> > 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
>> > >>>>>> )