At 08:16 AM 10/15/2002, Bill Stoddard wrote: >> After a million messages on related topics, I'm not sure that any two >> developers agree on all of the following topics: >> >> . how much to consider the needs of users relative to desires of >> developers >> >> . how hard to try not to break binary compatibility >> >> . how much to use 2.0 HEAD as a sandbox for new features >> >> . whether or not to start 2.1 now for auth changes >> >> Meanwhile, a number of the 2.0 users which have dared poke their heads >> into our mailing list point out through their comments that we have a >> PR problem (regardless of whether or not you agree technically on >> their particular concerns). > >Worth reading... >http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2882203,00.html > >I am generally in favor of maintaining a binary compatible/stable 2.0 cvs >repository. I think this may help the third party module authors to finally >do the work to get their modules running on Apache 2.0, which should help >improve the 2.0 adoption rate. What we call that repository is not >particularly important to me, though the name we choose may have PR >implications which we should be sensitive to. My suggestion is we freeze >2.0 MMN major bumps (unless there is a really, -really-, REALLY compelling >reason to do a bump) and start a new development tree for 2.1. Lets set some >goals for what we (the developers and the user community) want to see in 2.1 >and work toward those goals (ie, finish and agree on the ROADMAP we've >already started).
I have to concur with Bill on this (in spite of the fact that Jeff's arguments try to appeal to everyone's sensibilities.) I think the new proposal, that we have a maintenance tree stemming from Apache 2.0.43 using sub-subversions, follows from the fact that the list has been unresponsive to using revisions by the usual definitons. My question is just this... why do we feel that every revision must be 'completed'? Clearly, 2.0.x is new territory. Many will never upgrade to any 2.0.x simply because of the magic .0. in the middle. And this magic .0. has been GA for over six months. We got to 2.0 GA only because of tons of effort by many enthusiastic hackers. Right now, there is no place for such individuals to express their creative energy in improving the project, unless they want to get mired down in debates between breaking modules or configurations. It seems that the 'maintainers', the stodgy 'old men' of the group, want everyone to row together on bug fixes. That isn't how OS works. The folks with no interest in tracking down obscure bugs just leave, or quietly bide their time. The number of commits to the project is way down, meaning the rate of improvement for the project has slowed. Some folks are primarily focused on new development and ideas. Others are primarily focused on cleaning up functionality. Some have few interests outside of cleaning up grammar and legibility. And some want little more than to shape the architecture of the server, coding is simply a means to that end, for performance, scalability, security, etc. All of these are worthwhile contributions if done in the right context. Jeff especially hit one nail on the head; >. let those who are interested (not more than a few would be needed to > make it viable) maintain a separate tree based on 2.0.43, including > apr and apr-util... call it httpd-2.0.43, with potential releases > 2.0.43.1, 2.0.43.2, etc. Dropping the sub-subversion discussion for the moment, he hit on the magic words "let those who are interested". Those who want to maintain stable will, it's their itch. Those who want to make forward progress on the alpha/beta tree will have that outlet. I have an interesting idea about resistance to stability. Perhaps it's nothing less than immediate gratification. Most anyone who writes code wants users to adopt that code, the quicker the better. When the new code is the "right way"(R) we want people to immediately quit doing things the 'wrong way'. But 1.3 shows us that our end users don't always adopt the "right" code quickly. What's the penalty for stable/development trees? Users don't have the development code (at least not many) for some time, until the development tree becomes GA quality. But that's how it should be, and that's the only way we will ever find 1.3 adopters moving to 2.x. Anyone solid code contributions that don't break the API can always be merged back to the GA maintenance tree. We've done that for two years from 2.0 to 1.3, and it's worked. Bill
