RE: stable 2.0 trees
At the risk of racing too far ahead in this discussion, here is my suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for subsequent 2.1 series releases (except for a compelling reason, eg a security fix -requires- a bump). Why 2.1? No technical reason; purely a PR tactic to telegraph to the user community we are putting a lot of focus on maintaining binary backward compatability and to get rid of the *.0.* in the version number (yea, to appease the folks who are allergic to 0's in version numbers). New ROADMAP development is started in 3.0. thunderous applause/ I think Bill hit an important point here.version numbers signal a lot to the user community about the compatability of the code, and the pain in migrating to various versions. To a developer, the name of 2.0.43++ isn't so imporant - call it 2.0.44, call it 2.1.0, call it 17.9 - it's the same code. To a user, the migration from 2.0.43 to 2.0.44 should be easy. From 2.0.43 to 2.1 can be a little harder. It's much easier for end-users to understand releases if major functionality and/or API changes are coupled with minor version number bumps (instead of subversion bumps). From that perspective, changing the auth semantics (which have been pretty stable since at least early 1.3) 2.0.44 seems almost sneaky compared to changing them in 2.1.0. If minor version numbers are bumping weekly, that's not so good. If they are bumping quarterly or so as APIs change, that may well be healthier than carrying the 2.0 series on until the next major code reorganization. Version numbers are a marketing issue at least as much as a technology issue - here's an easy chance to give non-developers more insight into what is going on.
RE: Interesting Apache 2.0 project...
It could be a chicken-and-egg problem. If the developers of those tools don't have a lot of users asking for Apache 2.0 support, what is their motivation for providing it? They are probably like us, with lots of other things on their to-do lists. If we had a golden release, perhaps that would help change the situation. Really not trying to throw out flamebait, but... I think Greg hit the nail on the head here.There hasn't been much visibility to anyone not following this list (or even to many following it) of a timeline or roadmap to gold on 2.0. Do people know that all the major interfaces are stable?Are they? Not faulting anyone here, just pointing out that in the eyes of people not day-to-day involved, Apache 2 feels like it has been almost ready for a very, very, very long time.Did the additional development time yield a better product? Absolutely. But it did have a cost, at least in terms of public perception and excitement. Is there yet a consensus on a timetable for getting this to gold, or is it still a when it is ready approach? If the latter, it's going to be hard to get people very excited about even kicking the tires on the betas. It's going to be really hard to build momentum towards a release without a release target and active release management. According to the latest STATUS, we've had only one tag/roll event (2.0.31) in the last three months. It's also confusing to customers when at least two vendors are distributing Web servers that are based on 2.0 when 2.0 is still not fully baked. Justin's work on coordinating the .32 release has been extremely positive in this regard (way to go Justin!). A few more releases like this can probably get 2.0-gold out the door. Without that kind of focus on and ownership of releases, it's going to be really hard to ship this thing. - Danny PS A simple roadmap and timeline, like the one that Subversion has at http://subversion.tigris.org/project_status.html, would go a very long way towards addressing these issues.
RE: [PATCH] Add mod_gz to httpd-2.0
You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. A couple of points here - a lot of authors can't easily zip content before putting it on-line. Most people don't update Web sites via makefiles/scripts/whatever that can easily be extended to zip for them. A lot of people use FrontPage or the Windows Web Publishing Wizard - good luck explaining how to run gizp. Remember - most users of Apache are not software develoeprs. - a LOT of third party tools make it really hard to insert gzip output filters in the right place. Last I checked Tomcat 3.X did not support this without hacking at their classes.Other JSP engines are even worse. Don't even start thinking about some of the more pricey site-management suites. I haven't studied either of these two modules in depth, but the lack of a simple negotiate on gzip encoding for text/html option has been a major flaw in most (all?) Web servers to date. Putting one of these in the default Apache distribution would be a wonderful thing. - Danny
