On Fri, Jun 4, 2010 at 10:35 AM, Graham Leggett <minf...@sharp.fm> wrote:
> On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote: > > +1 for the continued, and perhaps more widespread, voluntary soliciting of >> approval in advance for changes which add new modules or other significant >> new function, or make other widespread changes, or change prerequisites in a >> meaningful way, or have been discussed in the past without resolution (or >> with outright rejection), etc., etc. (We don't need an explicit laundry >> list, or any additional policy, to codify the practical matter that multiple >> developers need to be ready and willing to cope with such changes when they >> reach the user base). >> >> This has been done countless times by numerous people in this successful >> decade, in spite of, and even for the continued viability of, the C-T-R >> policy. >> > > This creates an artificial "two tier" hierarchy of committers, those who > regularly "approve" changes, and those who don't. > Some people have more time and energy to read through more proposals and give their 2 cents one way or another. The important point isn't "approve" but "review and comment." Also, this is self-selecting so I don't see the issue of merit. A new person arriving here is certainly not going to feel confident enough > to step in and "approve" a change. What they'll see is a small group of > people "approving" changes made by a larger group of people, and they'll > naturally fall into the second "tier". > > The ASF is a meritocracy, and someone attains committership by proving > their merit to the point where they are invited to become committers: > > http://www.apache.org/foundation/how-it-works.html#meritocracy > > Where this has started to become a problem is when committers in the "first > tier" feel their "seniority" is enough basis for an objection to a code > contribution. sounds like a PMC issue to me > All committers are equal, and no matter how long a committer has been > around, they have to provide a justification for their objection to a piece > of code just as thoroughly thought out as the original committer is expected > to be thorough with their original contribution. > Equality is not the issue. I think I can describe the same conflict you are referring to in these very different terms: * some members of the community ask for feedback from their peers before making "big" changes; I think this implies that these members of the community are not interested in making the change unless there is reasonable agreement that it is a good thing to do, independent of any specific technical detail * some members of the community make "big" changes without looking first for the group sense of whether the change is generally accepted to be a good thing; I think this implies that these members of the community feel that their change should be in the server unless there is a specific reason to veto it This is not a black and white issue;"big" is in the eyes of the beholder, and there's no fixed membership in the two camps. These are just two philosophically different approaches related to the conflict you are discussing, and I think individual developers remain mostly in the same camp over time.
