Re: the wheel of httpd-dev life is surely slowing down, solutions please
On Wed, Nov 12, 2003 at 05:51:46PM -0800, Justin Erenkrantz wrote: > >Creating roles like this is just as bad as having chunks of httpd "owned" > >by one particular developer. (See below) > > I don't think you understand the role of 'patch manager.' On the projects > I'm involved with, that person's only responsibility is for ensuring that > the patches posted to the mailing list are entered into the right tool. > > I think that can easily be a volunteer, rotating job as you don't need to > do anything more than that. I don't know what this hypothetical tool looks like, but why wouldn't the person submitting the patch just use the tool directly? Seriously though, until we actually have a tool that we want to use, this part of the discussion is moot. > In the patch manager role, nothing would preclude others from adding > patches to the right tool. But, having someone whose responsibility it is > to ensure that patches get inputted into the tool on a timely basis is > goodness. On other projects I'm involved with, that person isn't an even a > committer. They don't have to understand what the patch does - just make > sure it is recorded and allow for annotation. > > And, it doesn't have to be on a 'timely' basis - once a week, you go > through and ensure that all [PATCH] messages are in the right patch > management tool. This lessens the number of dropped patches that we'd > have. (Bugzilla sucks at this, so I think we'd need a new tool.) Bugzilla wasn't designed for this, so yes, it sucks at it. I still maintain that the person submitting the patch should simply enter it into the patch system directly. Even easier would be a patch system that monitored the list for [PATCH] emails and tracked those automatically. We might come up with some standard syntax to help the patch tracking system know what version of httpd (or apr or whatever) the patch applies to. > >Woah woah woah. Are you discouraging people from thinking about big > >changes for the 2.2 timeframe? If someone has a revolutionary idea for > >the next generation of Apache HTTPD, who will stand in their way? Not I. > > Frankly, yes. > > I think our changes that we already have in the tree is about 'right' for > 2.2 (no big architecture changes, but lots of modules have been rewritten > and improved). It's just that no one has time or desire to shepherd 2.2 to > a release. And, I think we need APR 1.0 out the door before 2.2 can be > rationally discussed. [tangential issue] Why does it take some much time and desire to make a release? Shouldn't that be one of the easier things to do around here? > If we did any major changes from this point that require modules to rewrite > themselves, we'd need to go to 3.0 per our versioning rules. And, I'd > *strongly* discourage that. I don't think it's in anyone's best interest > to revamp our architecture at this stage. > > We don't need to give a moving target to our poor module developers. Only > by producing a series of high-quality releases can we ensure that module > writers will be confident in writing against 2.0 or 2.2. If we come out > with 3.x now, I think we'll just end up hurting ourselves in the long run > even worse than we are now. Let me pose a different angle: If our module API is so broken that we need to change it in an incompatible way, then don't you think the module authors would rather have the improved interface rather than being stuck with the broken one? In other words, the only time we actually talk about making drastic changes is when they are warranted. Therefore, being conservative about API changes merely serves to discourage creative development and that is _a bad thing_. -aaron
Re: should input filter return the exact amount of bytes asked for?
Justin Erenkrantz wrote: Thanks for the explanations Justin. Once I'll get some free time I'll need to revamp the filters chapter [1] to address the read mode issue. So far I was completely ignoring it :( (1) http://perl.apache.org/docs/2.0/user/handlers/filters.html Though it'd be nice to add a note re: APR_BLOCK_READ in the AP_MODE_READBYTES doc above. Or I guess may be it belongs to some filters tutorial... I'll note that I wrote an article on describing httpd-2.x's filters for some Linux magazine recently. I bet you can find back issues. As an aside, I never actually saw the final copy or the printed copy. So, don't blame me if it doesn't help. ;-) -- justin Is that the one you are talking about? http://www.linux-mag.com/2003-08/apache_01.html rbb wrote a bunch of filtering articles some 2 years ago or so too. It'd probably be nice to ask those magazines if we can dump them somewhere under the docs-2.0 project, versus linking to them, as ezines tend to move things a lot and even kill them. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the wheel of httpd-dev life is surely slowing down, solutions please
[EMAIL PROTECTED] wrote: The 'other' not-so-dedicated-but-certainly-interested developers felt 'shut out' of the 2.0 development cycle because it was obvious a lot of it was taking place 'off line' and nothing was being documented so they couldn't really get a good handle on what was going on in order to make a contribution. So they were mostly 'waiting in the wings' for a lot of the 2.0 DESIGN level decisions and concepts to become clear so they could 'jump in'. When I reworked mod_proxy for v2.0, it was one of the first modules to jump in and fully utilise the filter mechanism. Admittedly it took a while to get my head around the filter stuff, but once I had got it, it was fine. All the v2.0 mod_proxy development happened over weekends, and not on company time (a lot of it in a hotel room in Alsjo in Stockholm, but anyway). I feel the architecture jump from v1.3 to v2.0 was worth the effort, as the previous "one handler at a time" nonsense went out the window, replaced with a possiblity of "choose from these filters, and interchange them at will in new and interesting ways". The split of mod_proxy into mod_proxy and mod_cache would not have been possible without filters. I think the key thing is this: Apache v2.0 works, and better fulfils the requirements of people doing web hosting. Less development means there are less itches, and less itches means Apache v2.0 is a closer fit to user requirements than v1.3 was. Regards, Graham --
Re: Whitespace issue with apxs -a: activation for previously installed modules
Joe Schaefer wrote: Another approach would be to do nothing. don't tell me people have been reading the "wheel of httpd-ev..." thread :) I'd be happy to prepare a patch if this approach - to do nothing - is unacceptable. Of course, suggestions to make the patch as robust as possible would be enthusiastically welcomed. I don't see how allowing an arbitrary number of blanks could possibly hurt. Show us a tested patch. There will be a mad rush to see which committer will jump on it first. Okay, perhaps this is not the most realistic expectation ;)
Whitespace issue with apxs -a: activation for previously installed modules
Around line 590, apxs.in checks for a prior LoadModule
directive using:
foreach $lmd (@lmd) {
my $what = $opt_A ? "preparing" : "activating";
if ($content !~ m|\n#?\s*$lmd|) {
The problem here is that the $lmd portion looks something
like "LoadModule modules/mod_foo.c" with a FIXED number
or whitespace characters after "LoadModule". If a user adds
or deletes a few of those characters after a prior installation
of the module, the regexp will fail to match, and redundant
LoadModule directives will appear in his/her httpd.conf.
One possible (untested) solution is substitute '\s+' for
the whitespace between "LoadModule" and "modules/mod_foo.c":
foreach $lmd (@lmd) {
my $what = $opt_A ? "preparing" : "activating";
my $pattern = $lmd;
$pattern =~ s/\s+/\\s+/;
if ($content !~ m|\n\s+#?\s*$pattern|) {
Another approach would be to do nothing. I'd be happy to
prepare a patch if this approach - to do nothing - is
unacceptable. Of course, suggestions to make the patch
as robust as possible would be enthusiastically welcomed.
Thanks!
--
Joe Schaefer
RE: Apache 2.0 Uptake thoughts
Bill, Thanks for the great link. Here's one for you: http://www.securityspace.com/s_survey/server_graph.html?type=http&domaindir= &month=200310&servbase=YToxOntpOjA7czoxMzoiQXBhY2hlLzEuMy4yNyI7fQ==&serv1=QX BhY2hlLzIuMC40Nw== It's the historical market share of all servers overlaid with 2.0.47 2.0.47 is making progress but you can clearly see that it's taken many years to get any traction. Here's a question for you seeing that your closely related to Covalent where are the Covalent stats for sites running their version of Apache 2.x? How many servers have they shipped? Thanks Peter -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 1:33 AM To: [EMAIL PROTECTED] Subject: Apache 2.0 Uptake thoughts For those interested in the question of Apache 2.0 uptake, my favorite resource is http://www.securityspace.com/s_survey/data/index.html - where you get gobs of details. The upgrade/downgrade report helps identify if a release was a winner (mostly upgrading to, or through, that version) - or a loser (when you see some significant percentage fall back on earlier releases.) Drill down to Theft and Upgrades, choose Apache, then a specific release, e.g. 2.0.47. Scroll down to the version upgrade/downgrade list. Some of this is going to be random noise - multiple versions working in a distributed farm, pre-adoption testing, or difficulty reconfiguring the server (in the case of 1.3 -> 2.0 transitions.) But notably, 29.4k sites upgraded to .47 in October, and 1k sites backed down. Good retention, it indicates that the 2.0.47 release solved problems. (191 moved forward to 2.0.48-dev, not a bad thing at all.) The server details is also fun, no matter if you are comparing products or very specific releases. Here's where it's interesting. IIS 6.0 has 1.28% of the servers out there, that's about 5 1/3% of all IIS servers deployed. This, with a version that rolls out-of-the-box with specific flavors of the Windows OS. About the same time as IIS 6, Apache 2.0 rolled out. Ignoring for a moment the 9.13% of Apache servers that don't reveal their version whatsoever, ang ignorning rounding errors, 3.57% of the servers out there use some 2.0 version of Apache, so that 6% of Apache servers (identifying themselves) run 2.0 as opposed to another version. Personally, I'm pleased by a 6% uptake in a software application that doesn't have to change till someone needs the new features, given that we continue to provide the security patches people need for their existing 1.3 infrastructure. Of course it will only grow higher if folks trust 2.0 and can get their problems solved, which the current dialog in [EMAIL PROTECTED] I hope will help address. Just statistics to ponder as we approach next week. See you all in Vegas! Bill
Re: the wheel of httpd-dev life is surely slowing down, solutions please
At 12:36 AM 11/14/2003, [EMAIL PROTECTED] wrote: >'Individual' attempts to contribute are getting IGNORED >and the last few words of this message thread's subject >line are just asking to hear from the powers that be >what they intend to do about that ( solutions please ? ). Yes, I think that's the page everyone is on. How to solve this. >( and before you come back with the standard "Are YOU >willing to review patches, then?" at least I'll be honest >and say there's NO WAY right now or for the forseeable >future. Unlike you... I am NOT paid to work on Apache and >I just don't have the time. [...] Actually, I invest far more than 40 hours in my work and Apache time, and I know of many others (from other companies) that do likewise. But you just hit the nail on the head, "NO WAY". Nobody suggested that the core committers must single-handedly review the wealth of patches that are offered on this list and added to bugzilla! How can we communicate to this list, bugzilla users and others, that all it takes is to vote on the patch (in bugzilla, or by posting to this list) that the proposed solution actually solves the problem, and didn't break anything else in the process?!? "It works for me" are the four sweetest words to read when any of us are spending a free hour looking for patches to consider and apply! >Besides, I'm also about 100% >sure you don't want me reviewing patches for Apache. >Newcomers can go read some archived messages >if they are curious about the history there. ) If the casual reader is wondering why Kevin is unfortunately not been welcomed with open arms, by all means do go back over those archives. Then again, one doesn't need to scroll back more than the past day or few. Forgive in advance, Kevin, if I now tune you out. Bill
Re: the wheel of httpd-dev life is surely slowing down, solutions please
Although it's probably a little late to be responding to innuendo, the bare minimum points that need a response; At 12:36 AM 11/14/2003, [EMAIL PROTECTED] wrote: >There was a lot going down 'offline' and things were just >being 'announced' on the forum. That's the way development often happens. Pound on code for a week and present it when it's working. You are reading just a little too much cloak and dagger into things. >What you neglected to mention was that this now-famous >'303 - Second Street - San Francisco' in-person huddle that you >are talking about took place at ( you guessed it ) Covalent >Corporate headquarters. Yup - they hosted it, although had 1/2 the committers been in the same area on the east cost, our friends in Raleigh were happy to open their meeting room. >How long after that meeting was it that they hired you? >You were then ( still? ) in Nebraska, yes? I started consulting for them sometime after that meeting, when Ryan appealed for my help. I joined Covalent that following March. And nope, never NE, I've lived in Chicago most of my life, but for a few year sabbatical in upstate NY. Had never even met any Apache or Covalent folk in person till that meeting. >> I'm proud that I've been a contributor before Covalent >> and will remain ( proud ) even if I find other >> opportunities at some point. >Funny wording. Do you mean you aren't proud to be a >contributor now that you ARE at Covalent? Nope, I mean exactly that, I played with Apache for the heck of it and got alot out of the experience. It reassured me that C is not dead (another parallel discussion that's getting a little silly :-) And I'm equally proud to be part of Covalent, and proud of what Covalent employees have contributed to Apache, and the Apache 2.0 version. Bill And with that minimum response...
Re: the wheel of httpd-dev life is surely slowing down, solutions please
--On Thursday, November 13, 2003 1:51 PM -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: I'm confused then... I had thought that there were API differences (within httpd and apr) between the 2 trees in able to support some of the new features. I suspect that the biggest pain for a 2.0->2.2 migration (if we keep the delta roughly where we're at now) will be syncing with the deprecated APR functions, but that's more about APR going 1.0 than httpd going to 2.2. -- justin
Re: should input filter return the exact amount of bytes asked for?
--On Thursday, November 13, 2003 11:01 AM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote: Should we add an explicit explanation to AP_MODE_READBYTES: return at most readbytes data. Can't return 0 with APR_BLOCK_READ. Can't return more than readbytes data. I'd say the first and last one are equivalent statements. And, that APR_BLOCK_READ description belongs with the definition of APR_BLOCK_READ not AP_MODE_READBYTES. Also while we are at it I have a few more questions: /** The filter should return at most one line of CRLF data. * (If a potential line is too long or no CRLF is found, the * filter may return partial data). */ AP_MODE_GETLINE, does it mean that the filter should ignore the readbytes argument in this mode? I think so, yes. /** The filter should implicitly eat any CRLF pairs that it sees. */ AP_MODE_EATCRLF, does it mean that it should do the same as AP_MODE_GETLINE but kill CRLF? If not how much data is it supposed to read? Or is it a mode that never goes on its own and should be OR'ed with some definitive mode, e.g.: AP_MODE_GETLINE|AP_MODE_EATCRLF and AP_MODE_READBYTES|AP_MODE_EATCRLF? It's meant to be called right before we read the next pipelined request on the connection. Old (really old) Netscape clients added spurious CRLFs between requests. I don't see a clear rationale why it'd have to be 'combined' with other ap_get_brigade() modes. The only one that'd make sense (to me) is AP_MODE_GETLINE. Note that AP_MODE_EATCRLF doesn't necessarily return anything. It's wildly HTTP specific... Though it'd be nice to add a note re: APR_BLOCK_READ in the AP_MODE_READBYTES doc above. Or I guess may be it belongs to some filters tutorial... I'll note that I wrote an article on describing httpd-2.x's filters for some Linux magazine recently. I bet you can find back issues. As an aside, I never actually saw the final copy or the printed copy. So, don't blame me if it doesn't help. ;-) -- justin
Apache 2.0 Uptake thoughts
For those interested in the question of Apache 2.0 uptake, my favorite resource is http://www.securityspace.com/s_survey/data/index.html - where you get gobs of details. The upgrade/downgrade report helps identify if a release was a winner (mostly upgrading to, or through, that version) - or a loser (when you see some significant percentage fall back on earlier releases.) Drill down to Theft and Upgrades, choose Apache, then a specific release, e.g. 2.0.47. Scroll down to the version upgrade/downgrade list. Some of this is going to be random noise - multiple versions working in a distributed farm, pre-adoption testing, or difficulty reconfiguring the server (in the case of 1.3 -> 2.0 transitions.) But notably, 29.4k sites upgraded to .47 in October, and 1k sites backed down. Good retention, it indicates that the 2.0.47 release solved problems. (191 moved forward to 2.0.48-dev, not a bad thing at all.) The server details is also fun, no matter if you are comparing products or very specific releases. Here's where it's interesting. IIS 6.0 has 1.28% of the servers out there, that's about 5 1/3% of all IIS servers deployed. This, with a version that rolls out-of-the-box with specific flavors of the Windows OS. About the same time as IIS 6, Apache 2.0 rolled out. Ignoring for a moment the 9.13% of Apache servers that don't reveal their version whatsoever, ang ignorning rounding errors, 3.57% of the servers out there use some 2.0 version of Apache, so that 6% of Apache servers (identifying themselves) run 2.0 as opposed to another version. Personally, I'm pleased by a 6% uptake in a software application that doesn't have to change till someone needs the new features, given that we continue to provide the security patches people need for their existing 1.3 infrastructure. Of course it will only grow higher if folks trust 2.0 and can get their problems solved, which the current dialog in [EMAIL PROTECTED] I hope will help address. Just statistics to ponder as we approach next week. See you all in Vegas! Bill
