hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <...@cloudera.com>
Subject Re: [DISCUSSION] Combine committer lists in Common/HDFS/MapReduce
Date Mon, 09 Aug 2010 16:21:05 GMT
+1 to having a single committer list for Common, HDFS, and MapReduce.
The projects are currently closely aligned and there have been cases
where a committer couldn't commit what was logically a single patch
because it was split between Common and MapReduce.

I think we should make this change regardless of whether we ultimately
split the projects into TLPs, we merge them back into a single
project, or we keep them as three subprojects within the Hadoop TLP
(as they are now). I would also suggest that the question of what to
do about the project split, although related, probably deserves a
separate discussion.

Tom

On Fri, Aug 6, 2010 at 2:02 PM, Chris Douglas <cdouglas@apache.org> wrote:
> Hadoop developers tend to specialize in either HDFS or MapReduce, but
> given that:
>
> 0) Granting karma to Common is routine for a committer in either
> space; there are no Common-only committers
> 1) The majority of committers have been grandfathered into committer
> roles in all three projects
> 2) Many patches to Common require corresponding commits to both HDFS
> and MapReduce
> 3) Review-then-commit is usually sufficient notice for interested
> parties to comment
> 4) There have been few problems with committers pushing in patches
> without consulting someone more directly involved
> 5) Everyone on the PMC gets commit rights to all subprojects, anyway
>
> Perhaps it would make sense to give up on separate committer roles
> until the projects are separate TLPs.
>
> On the other hand:
>
> 0) Nobody has been independently added to both HDFS and MapReduce
> since the projects were separated
> 1) It could exacerbate the focus on MapReduce in HDFS, at the expense
> of other projects (like HBase).
> 2) HDFS and MapReduce are mostly independent communities and
> codebases; expertise in one does not imply fluency in the other
> 3) Granting veto power across projects can lead to deadlock despite
> consensus within that community
> 4) TLP status for either project may require untangling HDFS/MR roles
> that could be distinguished now
>
> Personally, I'm in favor of combining the roles. I trust all six of
> the committers made since the project split no less than those made
> earlier. Further, version control is sufficient for recovering from
> most, foreseeable issues. I have some concerns about "harmless"
> commits pushed through without an audit by the subproject's
> maintainers (a few in recent memory caused downtime in Y! clusters),
> but combining the roles seems like a worthwhile experiment.
>
> Thoughts? -C
>

Mime
View raw message