httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r925858 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/core.xml server/config.c
Date Wed, 31 Mar 2010 19:11:00 GMT
On 31 Mar 2010, at 2:33 AM, William A. Rowe Jr. wrote:

> On 2.2 branch, we are hamstrung by the stable shipping behavior, you  
> are
> right that we cann only fail 2 and 4.
> On trunk, all of these can fail by default, unless a permissive  
> directive
> is used to indicate the config author believes they know what they are
> doing, and accepts the consequences of chasing down their own typos if
> things just 'don't happen' when they change the mis-directed config.

No Bill, this is not how things are done.

You have just argued above for a brand new feature - a change to the  
behaviour of wildcard support in httpd. Ordinarily, one would propose  
this new feature on this list as a single issue and ask the rest of us  
for comments. Or you might have even patched trunk, and used that as a  
basis for the discussion over whether such a change was warranted. You  
would have provided evidence of problems encountered by people making  
typos by pointing out threads on the user's mailing list, you could  
have even just told us "I help lots of people who make these typos,  
and they really need to be helped" and we would have believed you.

But you didn't do that. You took an entirely unrelated feature, the  
extension of wildcard support to directories in addition to files, a  
feature that had been explicitly approved by three people as per the  
long standing voting rules of this project, and you vetoed it, on the  
basis that somebody else's work didn't have your unrelated change  
built into it. Did you propose or discuss your unrelated change on the  
list beforehand? No. Did you respect the opinions of the three people  
who were happy with this change? No. Did you provide any evidence that  
your feature was even necessary? No. Did you provide your own patch,  
implementing the change you wanted? No. You went straight for the  
veto, do not pass go, not not collect 200 pounds. You were so  
confident in your veto that you didn't even stop to check if your veto  
had hit the list (it hadn't, thanks to dodgy mail clients).

Seriously, this kind of thing has got to stop.

> Yes, we've all seen vetoes thrown around without any explanation,  
> without
> the author willing to revisit, refine and reclarify the objection,  
> in light
> of additional information.  You and I did refine and reclarify this  
> veto,
> many times, in the process.  In the end, we were able to refine a  
> solution
> without having to go to the extreme of a F2F powwow.  That's a  
> positive.

No Bill, I refined the solution. I provided the patch, I provided the  
documentation, and I provided most of my saturday, a lot of my sunday,  
and my whole monday night and tuesday night trying to make sure that a  
problem that has negatively affected a large number of people stayed  
solved. You provided the whip, and undid most of the work by backing  
out an approved backport, that was pretty much it.

> And yes, the project is more than willing to lose contributions  
> which are
> not thought out; we do so frequently if the bugzilla  
> 'PatchAvailable' tag
> is a measure of which patches are 'interesting'.  The difference is  
> the
> disagreement between an arbitrary contributor v.s. a committer.

No, we lose patches because of limited time from limited committers.  
Do not underestimate or try to downplay the importance of a patch from  
an arbitrary contributer. They've spent their own time and effort  
formulating the patch, contributing it to us, justifying its  
inclusion, and our license obliges nobody to do that.

Encourage arbitrary contributers by respecting the work they put in  
and they become regular contributers, and then they become committers,  
and then members.

> Your definition of progress isn't necessarily my definition, or  
> Paul's or
> Jim's or Ruediger's.  Each committer is here looking at the code  
> from their
> own perspective, and I hold the greatest respect for the committers  
> who
> clearly are looking out for the interests of several groups of users  
> at
> once, not the committers who might be here to advance only their own  
> agenda.
> In other words, TMTOWTDI, most of the time, and collaboration means  
> moving
> forwards to let as many improvements in that don't disrupt other  
> groups of
> users or developers.

I honestly couldn't care in the slightest which committer has  
contributed what, or what their agenda is, all I care about is whether  
a contribution adds value to the project on a case by case basis, and  
whether the lives of webmasters and end users are made more pleasant  
as a result.

I have the greatest respect for the committers who have stuck around  
and do actual work, and that includes you Bill, and is why we're  
having this discussion.

Currently it is my agenda to take the inhouse experience of one of the  
world's biggest media organisations whose average daily traffic  
pattern would be described as a "distributed denial of service attack"  
by everyone else, and share that experience with other users of the  
httpd server. It also happens to be the agenda of a number of other  
ASF members working for the same organisation.

Given the number of people who want to build "fast" webservers these  
days, I am focusing on making sure there are still "reliable"  
webservers available in the market, of which httpd is arguably still  
the best example to date.

>> Months and months of work by various ASF members convincing people in
>> this particular organisation that it is a good idea to pass their
>> changes upstream to the original project instead of hiding their  
>> code in
>> silos, and now they're told "you can just do what you've been doing  
>> all
>> along, keep your changes to yourself". Thanks for the help Bill.
> You presume that all changes are suitable as-is?

No, I presume that changes will be suitably peer reviewed by other  
members of this project, commented on and changed as appropriate, and  
if proposed for backport agreed upon by at least three of the  
project's members, in the way that is has always been, or at least how  
it's been during the decade-and-a-bit I've been contributing patches  
to this project. I do not presume that changes will be stomped on and  
killed through misuse of the veto mechanism.

> Include strict path is an improvement in 2.2, yes, although one that  
> will go
> away in trunk (since all Include statements should find some file to  
> Include,
> unless the clever/attentive adminstrator tags them 'optional').  I  
> suspect
> that an IncludeOptional directive is more efficient, I'm happy to  
> offer the
> patch to your patch after I svn revert my local code changes.  The  
> cost of
> another hashed directive is less expensive than parsing for multiple  
> args.

Either is as easy as the other, I implemented both in the last few  
days. And I don't mind whatever feature you put in, as long as I and  
everyone else has the option to switch it off.


View raw message