hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhruba Borthakur <dhr...@gmail.com>
Subject Re: [DISCUSSION] Combine committer lists in Common/HDFS/MapReduce
Date Sat, 14 Aug 2010 01:53:19 GMT
+1 on combining committers list for common + hdfs + mapreduce. It is mostly
the same set of users who contribute to all three projects.

thanks,
dhruba


On Mon, Aug 9, 2010 at 11:47 AM, Konstantin Boudnik <cos@apache.org> wrote:

> +1 on combining the committer roles in one (as Doug has mentioned
> elsewhere,
> all three are feel like a single project and are released as such,
> therefore
> it doesn't make much sense to split committers). In effect, MR testing that
> pulls in "external" HDFS dependencies works as a poor-man integration
> testing.
>
> -1 on combining the projects back together. While having them separated
> might
> cause an extra maintenance burden, the same separation forces more clean
> design decisions.
>
> Cos
>
> On Fri, Aug 06, 2010 at 02:02PM, Chris Douglas 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
>



-- 
Connect to me at http://www.facebook.com/dhruba

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message