Date: Fri, 1 Mar 1996 17:47:47 GMT
From: Paul Richards <p.richards@elsevier.co.uk>
Message-Id: <199603011747.RAA20189@tees>
To: new-httpd@hyperreal.com
Subject: Re: Patches patched... or something
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: +skESAa59VSfx0y8uqcW1w==
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com
Status: O

Umm, guys, calm down a minute. There's some valid positions here on both
sides.

> >Sure. People. But people isn't me. And I refuse to patch a patch to Apache
> >that makes it not compile on my system, and probably dozens of others.
> >(HP-UX doesn't have <paths.h>, SunOS doesn't have <paths.h>. BSDI and
> >Linux do, but at that's only half the systems I have access to.) If you
> >want to patch it, or get someone else to patch it, be my guest. But I'll
> >just have to remove the line and then the patch will be useless. 
> 
> Okay, so anything else you put there, that doesn't automaticly compile
> on Linux, BSD, and/or SunOS we can veto?  Is this the new rule now? 

My ruling would be (and I'm not king of the hill either, just giving my
opinion), if it work's on your box commit it and then let people
with other box's fix it so it works for them. This would generally be good
practice for getting code into the tree quickly and allowing people with
access to the other systems to do what's necessary for it to be portable.

My only overriding rule is, *if it's broken on your box it has no business
in Apache*. If it's working for you then you've done all you can and committing
it is the correct next step.

> >And as for the log_ignore_cmd patch, there's still, as far as I know, 
> >Brian's outstanding admonation against including the feature, regardless 
> >of the patch itself. And the guidlines posted by Paul (yes, I got them) 
> >say that changes like that should be peer reviewed first. I just didn't 
> >feel comfortable applying the patch. That's all.
> 
> Who the hell made you the king of hill?  To say which patch can and 
> can't be included.... if you took it upon yourself to include the patches 
> from the for_apache_.xxxx directory, I don't think that gives you automatic
> veto power over any patch you don't like. 


It was reasonable for this patch to not have been put in when the others
were. We're still moving from one system to the other and this patch I think
would fall into the category of "potentially contentious change, better to
get second opinion before committing to save tears later".

There's nothing stopping someone else putting this patch into cvs but since two
people have already looked at it and feel "uncomfortable" with it then it is
clearly a change that needs discussing.  I'm not sure it's a desirable feature
either so it's definately a feature issue and not a clear cut fix that no-one's
going to argue about and is, in fact, a good example of the sort of change that
should be raised here first rather than stuck straight into cvs.