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
code
refactorings."
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:
http://www.apache.org/foundation/how-it-works.html
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 http://www.apache.org/foundation/how-it-works.html:
"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.
Regards,
Graham
--
