"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > 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.
just curious... which proposal corresponds to "want everyone to row together on bug fixes"? > 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 would expect that anybody working on maintaining the extremely stable release would be involved with the alpha/beta tree too, since the very definition of the extremely stable release (only critical fixes always close to release-able since there aren't many changes to test) means that there isn't much work associated with it. Bill S and I had some discussions over lunch which make me suspect that I'm not communicating very well the spirit of what I proposed. First, I'm pretty happy with what is going on in 2.0 HEAD now. I don't think MMN is changed gratuitously, I don't think the code gets destabilized a whole lot on a regular basis, I think that having some aspects of the config change (i.e., the auth issue) change at this point in the >=2.0 lifetime is not completely unreasonable (scripts can certainly help admins). I think we're still at a point where changing MMN is reasonable under certain conditions. My proposal was just to allow extremely conservative/stable releases which any current 2.0 site could upgrade to with no fears (either of new Apache problems from some of the itch scratching or breaking compatibility with 3rd party modules) in order to pick up a fix for a security problem they're concerned with. This proposal wasn't intended to address the big picture of how overall development proceeds and which changes can be delivered within 2.0 framework or some new set of ideas. It was only to calm the concerns of sites running 2.0 which have things working pretty well but are concerned that the 2.0 tree has enough activity that they risk breaking something else by picking up a new 2.0 release. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
