On 6/4/2010 9:35 AM, Graham Leggett wrote: > On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote: > >> >> 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.
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. 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. 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. On 6/4/2010 9:19 AM, Graham Leggett wrote: > On 04 Jun 2010, at 2:55 AM, William A. Rowe Jr. wrote: > >> 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. What the dev list is for is to help filter this collective consensus. This is always preferable to what can degrade into a commit battle. And many contributions were offered first to dev@ because of their scope. Often accepted, sometimes rejected. Occasionally, ejected after acceptance. At some points when I was actively teaching or doing repair projects or the computer lab, I had the keys to my church. There was no church.org/dev/ site with access policies, no do's and dont's. People with keys were just trusted to use them responsibly.
