Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
>> > >>>>>> )
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB