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

Switch to Threaded View
Hadoop >> mail # dev >> [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack


Copy link to this message
-
Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack
Hadoop's bylaws do draw finer distinctions than the Apache voting
guidelines document, but we follow the same general principles that
are described there.

As I understand it, the rationale for using consensus for code is that
everyone needs to agree on everything in the codebase or we've
disenfranchised some.  We share a single code repository and we need
to all agree on what goes into it.  A release does not require
majority since if someone doesn't agree on the timing of a release
they can choose to make another at a different time, but every change
that goes into each release requires consensus.  We also require
consensus for committers and PMC member votes so that we have a group
that's coherent and is able to reach consensus on code changes.

Re-writing bash scripts in Python is neither a release nor other
procedural issue.  It involves changes to the software we maintain and
seems to fall clearly into the "code change" category.

If you disagree then perhaps you'd like to propose a change to the
bylaws so that scripts have different rules than other kinds of
software, but I don't yet see the rationale for such a change.

Doug

On Mon, Dec 3, 2012 at 5:22 PM, Matt Foley <[EMAIL PROTECTED]> wrote:
> No, but it speaks to whether the Hadoop bylaws can extend the Apache voting
> procedures and draw finer distinctions.  For example, the Apache voting
> procedures only identify 3 types of votable issue, while the Hadoop bylaws
> identify 9 types of votable issues.
>
> If we were forced to fit "development tools" into one of the three
> categories cited by the Apache voting procedures, it would be fitting a
> square peg in a round hole.  Since we can instead look at the 9 categories
> provided by the Hadoop bylaws, we can acknowledge that "development tools"
> was an overlooked category.  But in my opinion it certainly doesn't fit
> into the "code change" category.  Tooling is a meta-issue regarding HOW we
> do what needs to be done.  In this case, whether we allow a
> platform-independent solution, or force contributors to maintain parallel
> scripts in multiple platform-specific languages for no reason.
>
> --Matt
>
>
> On Mon, Dec 3, 2012 at 3:57 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley <[EMAIL PROTECTED]> wrote:
>> > The apache voting process contradicts the Hadoop bylaws:
>> > http://www.apache.org/foundation/voting.html says that only PMC members
>> can
>> > make binding votes on code modification issues, but
>> > http://hadoop.apache.org/bylaws.html says that Committers can make
>> binding
>> > votes on them.  Does that mean the Hadoop bylaws have to change?
>>
>> This may be a little atypical but I don't see any harm.  The Hadoop
>> PMC is willing to respect the veto of any committer as binding.  I'd
>> worry more if we tried to reduce vetoes to a subset of the PMC than
>> extend it to a superset.
>>
>> Do you think this is problematic?
>>
>> Doug
>>