Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: PR42829
Date: Fri, 30 May 2008 17:55:09 +0200
User-Agent: KMail/1.9.9
References: <019E26AF-FE2A-4B14-B058-FCE1E7FACD4A@jaguNET.com>
 <ef815a070805292329q248a7a6bxa6de6f2debe03b8e@mail.gmail.com>
 <20080530123415.3ce7b734@grimnir>
In-Reply-To: <20080530123415.3ce7b734@grimnir>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200805301755.10220.sf@sfritsch.de>

On Friday 30 May 2008, Nick Kew wrote:
> I don't think I share your implied view about how grave this is.

I guess this is the main (or only?) problem with this patch/bug. I got 
quite a few people complaining about it and therefore I wanted to fix 
it.

> I respect your opinion, but when maintaining your own patches,
> please consider also the problems discussed in my article at
> http://www.regdeveloper.co.uk/2006/11/04/apache_packages_support_va
>cuum/ (which goes to the heart of why Debian may get a pretty
> hostile reception amongst some Apache folks).

Yes, this is definitely a problem, but not easy to fix. I hope I will 
find some time soon to try to improve the situation. In any case the 
problem is less about patches but more about the configuration and 
the additional scripts we ship with apache. For example the 
configuration is split into many small files because this makes 
upgrades easier because of the way dpkg handles config files. 

> > To take it to the extreme, a fork being called 'Apache' isn't
> > acceptable either.  Please work with us here, even though it's a
> > very low barrier for you to put patches in your package, much
> > lower than to get it applied upstream (here).

Fixing bugs is not forking. We don't include many patches that are not 
either bug fixes or related to build or file system layout issues.
For example we don't add features or change the behaviour (unless the 
component comes in a separate package that is clearly marked as 
non-standard, like the mpm-itk). And for the bug fixes, these are 
usually from branches/2.2.x or from the Apache bugzilla.

> To be fair, I think Stefan _is_ working with us: he's put his patch
> in bugzilla, and (now, though not originally) he's raised it on
> the list.

I raised the issue in January 
(http://marc.info/?l=apache-httpd-dev&m=119945416529706&w=2) and 
there was some discussion with Joe Orton, but no conclusion about 
what would be the proper fix. But since I had a fix that worked for 
me, I didn't see any reason to revert the patch.

My mail in January already mentioned that the patch is in Debian, but 
I guess now after the openssl debacle people are more sensitive. If 
you think it would help, I could go through our patches and post a 
list of the non-Debian specific ones here.

Cheers,
Stefan