Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of mfoley@hortonworks.com
 designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Reply-To: mattf@apache.org
Sender: mfoley@hortonworks.com
In-Reply-To: 
 <CAKtuutHR4_5hqx82FQe-179fYdupEhd2C8wV3EfR_=Oo1QQTog@mail.gmail.com>
References: 
 <CA+z3+9EU-AEWnfr9CBherXgq55eGZwrW--tO6ZMSh_EMEfpXyQ@mail.gmail.com>
 <CAPn_vTvNHGrv85+gLBbtLhts232F7zsigqo9xzW2-KLJ6HWRyA@mail.gmail.com>
 <CAEfeEE-Qorto0phk1qOx+J=YGb=aqk0a5_tjEYq5=cPPTUHFgQ@mail.gmail.com>
 <CALwhT95wuZ-ZSdTWvHBfe=zzXpJ1AJ8rg_GY5y7gPJDBGG1RJw@mail.gmail.com>
 <CALF7aMTT8pk94WBTA7Zwi2+JSgFQL3xXcTBTbW27hosjrMDq1A@mail.gmail.com>
 <CA+z3+9G-jMmjCuiGVOvrG8SRwwmMwaoYeiJNKrGd45r+YcfJEA@mail.gmail.com>
 <DDDA99B6-B38D-439E-85F5-07789079A043@jpl.nasa.gov>
 <CA+z3+9GMus=wGmL9R+5fsULp=kDYTt=jX1q7G4Zeo1oLvC=ZUQ@mail.gmail.com>
 <CAKtuutHR4_5hqx82FQe-179fYdupEhd2C8wV3EfR_=Oo1QQTog@mail.gmail.com>
From: Matt Foley <mattf@apache.org>
Date: Wed, 22 May 2013 12:39:15 -0700
Message-ID: 
 <CA+z3+9ECBkXh=qJxj28JSKHSJ0VLPG_TuAaxiLS9pgin3diJMQ@mail.gmail.com>
Subject: Re: [PROPOSAL] change in bylaws to remove Release Plan vote
To: Konstantin Shvachko <shv.hadoop@gmail.com>
Cc: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a883a67454204dd53ba75

--047d7b3a883a67454204dd53ba75
Content-Type: text/plain; charset=ISO-8859-1

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.hadoop@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 <mattf@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.mattmann@jpl.nasa.gov> wrote:
>>
>> > Why repeat just tally new ones?
>> >
>> > Sent from my iPhone
>> >
>> > On May 21, 2013, at 6:58 PM, "Matt Foley" <mattf@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 <
>> mahadev@hortonworks.com
>> > >wrote:
>> > >
>> > >> +1.
>> > >>
>> > >> thanks
>> > >> mahadev
>> > >>
>> > >> On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla <
>> kasha@cloudera.com>
>> > >> wrote:
>> > >>> +1 (non-binding)
>> > >>>
>> > >>>
>> > >>> On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey
>> > >>> <jitendra@hortonworks.com>wrote:
>> > >>>
>> > >>>> +1
>> > >>>>
>> > >>>>
>> > >>>> On Tue, May 21, 2013 at 4:02 PM, Eli Collins <eli@cloudera.com>
>> > wrote:
>> > >>>>
>> > >>>>> +1  thanks Matt.
>> > >>>>>
>> > >>>>>
>> > >>>>> On Tue, May 21, 2013 at 2:10 PM, Matt Foley <mattf@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/>
>> > >>
>> >
>>
>
>

--047d7b3a883a67454204dd53ba75--