httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: What's next for 2.2 and 2.3/trunk?
Date Fri, 04 Jun 2010 20:23:11 GMT
On 04 Jun 2010, at 6:06 PM, William A. Rowe Jr. wrote:

> All individuals are invited to chime in when a proposal is raised,  
> and to
> invest the time in reviewing the proposal.  That includes non  
> committers.
> There are no "tiers", except for contributor, committer, and project  
> committee
> member.
> There are committers who continue to amass esteem by regular and  
> sustained
> review of the code contributions - those CTR, RTC, and even  
> committing code
> for the non-committers provided on the dev@ or bugzilla channel.

And in so doing creating the "first tier" and "second tier" that I'm  
talking about.

Committers are expected to make regular and sustained review of the  
code contributions from day one, in fact the basis by which that  
committer was invited to be a committer was *because* they made  
regular and sustained code contributions.

There is no "continue to amass esteem".

The reason this is dangerous is because if this is allowed to happen,  
we risk someone who has "amassed esteem" to start using "esteem" as  
currency instead of a solid technical justification. Just because  
someone has been around a long time does not relieve them of the  
obligation to solidly justify their position on an issue or their  
rejection or acceptance of a piece of code.

> There is no new layer of bureaucracy, nor is it even bureaucracy.   
> It's the
> desire of the entire project to see big ideas, or big refactorings,  
> come to
> the list first to be vetted.  That has always been there.

No, to quote you:

"CTR is fine for all normal fixes.  RTC is always preferred for major  

I ask you this: What constitutes "a modest new feature"? It's not a  
fix. It's not a major code refactoring. But modest new features have  
been strongly objected to by a small group of people on this list who  
insisted it was a clear cut case of "should have reviewed first", on a  
branch that is CTR.

I have absolutely no objection whatsoever to the need for review of a  
major code refactoring. I have absolutely no objection whatsoever to  
those who express the opinion that a piece of committed code is  
inappropriate or unnecessary. But we've reached the point where people  
want anything that isn't any more than a fix to be reviewed first  
*before* commit as a matter of procedure, and this wooly grey area  
cannot continue.

> Graham, I'm a little bit concerned you aren't reading what a number  
> of the
> experienced committers are saying to you.  Please take the time to  
> reread
> these posts, perhaps they will be clearer on a second or third  
> reading.

And here again, you attempt to create the "two tier" hierarchy by  
referring to "experienced committers", as if they are a group apart  
from "committers".

Wearing my hat as a long standing member of the foundation - which  
gives me no special status on this or any other ASF project, but does  
reflect my continued concern about the foundation and how it is run  -  
I am really concerned that this very non-ASF set of practices are  
being perpetuated within the project that is supposed to be the model  
for how an ASF project is run. And given the recent threads on various  
ASF lists on this topic, I am not alone in my concern.

Please take time to read this, in detail:

Particularly, this:

"Within the ASF we worry about any community which centers around a  
few individuals who are working virtually uncontested. We believe that  
this is detrimental to quality, stability, and robustness of both code  
and long term social structures."

I believe the "amassed esteem" or "experienced committer" you have  
referred to above fits squarely on the definition of "centers around a  
few individuals who are working virtually uncontested", and I am  
concerned that people might believe their "experienced committer"  
status somehow gives them more authority than another committer. It  
does not.

>>> CTR is fine for all normal fixes.
>> No, it has been the policy of the project for many years that CTR is
>> fine on trunk for *all* contributions.
> *All* contributions have never been welcome.  Those that fit within  
> what
> the PMC collectively believes httpd should contain are always welcome.

This isn't how the ASF works.

The PMC does not dictate to end users what they want or what code  
should be accepted. Any objection by any PMC member needs to be backed  
up with a solid technical justification, just like any committer is  
required to.

Or to quote from

"The role of the PMC from a Foundation perspective is oversight. The  
main role of the PMC is not code and not coding - but to ensure that  
all legal issues are addressed, that procedure is followed, and that  
each and every release is the product of the community as a whole.  
That is key to our litigation protection mechanisms."

The key words are "not code and not coding". The only reason a PMC  
might reject code is if the code did not address the legal  
requirements (licensing, etc), or did not follow procedure. If a PMC  
member wanted to reject code for a reason other than these, they would  
reject the code wearing their committer hat, and what that means is  
that they would be bound by the same requirements for providing  
justification that binds any committer.

To sum up, this is a group of peers, and the group only works when we  
respect each other's contributions and views on an equal basis.


View raw message