For the records, I am +1 on having a single set of committers for
hdfs , mr and common. For me, all committers do not need to be equally
good, or have to reach a grand bar; but rather I should trust that
person to be a team player.
Dhruba
Sent from my iPhone
On Aug 19, 2010, at 4:00 PM, Nigel Daley <[email protected]> wrote:
On Aug 19, 2010, at 1:03 PM, Doug Cutting wrote:
On 08/19/2010 12:48 PM, Stack wrote:
I do not see how a combined contributor list could act as
friction on
the ongoing break-up of the hadoop project -- something I'm in favor
of -- nor get in the way of the development of distinct mr/hdfs
user+dev communities; it seems to me that that project can progress
independent of who can commit where.
I agree.
Many projects manage such things with trust, not with rigid ACLs.
Some committers are trusted to commit just test code, some just
documentation, and some deep implementation details in particular
areas of the code. But should any committer wish to manage a
release, or even commit a patch outside of their normal domain of
expertise (if it's been reviewed by someone with expertise in that
domain) they can. Over time they can gain trust in new areas of
the project. In such projects, adding a committer merely implies
that you trust someone not to overstep their abilities. If someone
consistently suggests that patches are ready for commit which
others feel are not, then they won't earn that trust and be invited
to become a committer. Thus committership is not about deep
technical abilities, but personal trust not to violate social
contracts. Erecting walls within the community of trust via ACLs
doesn't seem productive.
Doug
Agreed. Anyone want to reconsider their vote?
