hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhruba Borthakur <dhr...@gmail.com>
Subject Re: project split coming soon!
Date Sat, 16 May 2009 00:03:36 GMT
The goal of my earlier email was to keep the committer community together
instead of splitting. Most of the people in the committer community have
worked together very well, and I would hate to see it being split apart (at
least, in spirit).

>Owen made a guess, and posted notice.  Anyone who has committed to mapred
or hdfs code in the past year, or expects to soon but was
>not on Owen's mapred or hdfs lists should speak up now.

Ok, thanks for the clarification.
-dhruba


On Fri, May 15, 2009 at 3:12 PM, Doug Cutting <cutting@apache.org> wrote:

> Jim Kellerman (POWERSET) wrote:
>
>> I have to agree with Dhruba. I don't see the need to split up committers
>> (esp if they are on the PMC).
>>
>
> PMC members are moot here, since all PMC members have permission to write
> anywhere in the Hadoop tree.  So the question is whether all non-PMC
> committers to Core should also be given commit access to the new HDFS and
> Mapred subprojects split off from Core.
>
> As a general rule, we remove folks commit permission if they have not
> committed in a year.  We usually ask first, and, if someone claims they'll
> start committing again soon, we give them the benefit of the doubt.  So a
> reasonable way to do this would be to construct these lists based on those
> who've committed to the relevant areas in the past year, but that might be
> difficult to determine precisely, pre-split.
>
> Owen made a guess, and posted notice.  Anyone who has committed to mapred
> or hdfs code in the past year, or expects to soon but was not on Owen's
> mapred or hdfs lists should speak up now.  That seems like an entirely
> reasonable process, consistent with the way we've managed committer lists in
> the past.
>
> An alternative might be to put everyone on all the lists, then, in a year,
> remove those who've not committed to a subproject.  That might be simpler to
> implement.  I would not veto either approach.  Owen is willing to do the
> work here, and I'm willing to let him decide.
>
> Doug
>

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