Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 65158 invoked from network); 13 Apr 2009 17:23:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Apr 2009 17:23:02 -0000 Received: (qmail 39525 invoked by uid 500); 13 Apr 2009 17:23:00 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 39402 invoked by uid 500); 13 Apr 2009 17:23:00 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 39393 invoked by uid 99); 13 Apr 2009 17:23:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Apr 2009 17:23:00 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates 72.14.220.153 as permitted sender) Received: from [72.14.220.153] (HELO fg-out-1718.google.com) (72.14.220.153) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Apr 2009 17:22:53 +0000 Received: by fg-out-1718.google.com with SMTP id e12so670428fga.17 for ; Mon, 13 Apr 2009 10:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4/3uC9EOgfejJYzYLmE6NoIZoZd0kp0z3Q6ykSebtTg=; b=rPdYzOUvPFhANnanrCSXNgohw+iui2ydOYrWWmZnDHgYrKS3n/vJABzE2qxCjSi4zs GDpRh9op1FTDUOy5h+ovwV2tp2dSR/ExavtB9MuBWASjUMKGKvgkI5CYqWP81a/WqNWQ iO33QCsIsGzTh/lcVXXa85Yf/wxa4xfcGwwrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vq+JYcvoomWu50jLHQlws/SG6Cml6+4AGuqMen76JZ69OVfz/KFSbNhFEzCWbB0Bbb BdhJCif6AvP4zGjxW2Fs3+lluZyT0CMNj0pAjvJ0dAA2oGhC6KNIX52XITsHyDvpYeak 1uqCxctofi+qVjefqkBzGXl6RG278qQSX0vOQ= MIME-Version: 1.0 Received: by 10.86.80.5 with SMTP id d5mr4959872fgb.6.1239643351824; Mon, 13 Apr 2009 10:22:31 -0700 (PDT) In-Reply-To: <49DFC8E0.9000407@pearsoncmg.com> References: <49DFC8E0.9000407@pearsoncmg.com> Date: Mon, 13 Apr 2009 13:22:31 -0400 Message-ID: Subject: Re: mod_fcgid support From: Jeff Trawick To: dev@httpd.apache.org Content-Type: multipart/alternative; boundary=000e0cd297f0a23bed046772f506 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd297f0a23bed046772f506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Apr 10, 2009 at 6:32 PM, Chris Darroch wrote: > Hi -- > > Jeff Trawick wrote: > > Many people use mod_fcgid on Apache 2.0/2.2. The message should be that >> mod_fcgid development has moved to the ASF, and existing users are not being >> left behind in the transition. So a branch for mod_fcgid 2.x is maintained >> for httpd 2.0/2.2 users just as our own stable branches are maintained (FAR >> beyond emergencies, at least for 2.2.x). >> >> This isn't necessarily in opposition to what you said, but some might read >> it as something like "Apache took over and they won't distribute fixes that >> work with my existing configurations except in extreme circumstances." >> > > I think that's something we want to avoid. (Sorry for the slow > response; I'd like to say I've been giving this deep thought but > actually I've just been distracted with other work for a bit.) > > It's also worth assuming, I think, that mod_fcgid isn't going > to be back-ported and included in the 2.2.x distribution anytime soon. sure; IMO it doesn't ever need to be included in the 2.2.x distribution > > > Given that, I suppose we should look at continuing a 2.x branch > for mod_fcgid (with improved autoconf magic, obviously), at least > until a httpd 2.4.x is released with mod_fcgid in it. > > It's slightly inconvenient but I'll willing to start digging into > the autoconf stuff and generally trying to get a branch going > before we add it into httpd trunk. How do others feel? As I understand it, the current state of mod_fcgid is that it has been imported into the httpd project's mod_fcgid subtree, it has been cleaned up w.r.t. licensing and coding style and some other concerns (what's in readme vs. other files), but no real code changes have been made. Can we * import the cleaned up mod_fcgid into httpd trunk for expected inclusion in the next httpd release (2.4 or 3.0 or whatever it is) ** work on autoconf and incompatible code changes there (httpd trunk) ** if for some reason this work doesn't proceed fast enough for mod_fcgid to be included in the next httpd release, it can be axed from the future httpd 2.4/3.0/whatever branch when that branch is created * use the httpd/mod_fcgid subtree for bug fix releases of mod_fcgid (retain compatibility with httpd 2.0/2.2 as well as existing mod_fcgid configurations) --000e0cd297f0a23bed046772f506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 10, 2009 at 6:32 PM, Chris D= arroch <chris= d@pearsoncmg.com> wrote:
Hi --

Jeff Trawick wrote:

Many people use mod_fcgid on Apache 2.0/2.2. =A0The message should be that = mod_fcgid development has moved to the ASF, and existing users are not bein= g left behind in the transition. =A0So a branch for mod_fcgid 2.x is mainta= ined for httpd 2.0/2.2 users just as our own stable branches are maintained= (FAR beyond emergencies, at least for 2.2.x).

This isn't necessarily in opposition to what you said, but some might r= ead it as something like "Apache took over and they won't distribu= te fixes that work with my existing configurations except in extreme circum= stances."

=A0I think that's something we want to avoid. =A0(Sorry for the slow response; I'd like to say I've been giving this deep thought but actually I've just been distracted with other work for a bit.)

=A0It's also worth assuming, I think, that mod_fcgid isn't going to be back-ported and included in the 2.2.x distribution anytime soon.

sure; IMO it doesn't ever need to be included in the 2= .2.x distribution


=A0Given that, I suppose we should look at continuing a 2.x branch
for mod_fcgid (with improved autoconf magic, obviously), at least
until a httpd 2.4.x is released with mod_fcgid in it.

=A0It's slightly inconvenient but I'll willing to start digging in= to
the autoconf stuff and generally trying to get a branch going
before we add it into httpd trunk. =A0How do others feel?
=
As I understand it, the current state of mod_fcgid is that = it has been imported into the httpd project's mod_fcgid subtree, it has= been cleaned up w.r.t. licensing and coding style and some other concerns = (what's in readme vs. other files), but no real code changes have been = made.

Can we

* import the cleaned up mod_fcgid into httpd trunk for ex= pected inclusion in the next httpd release (2.4 or 3.0 or whatever it is)** work on autoconf and incompatible code changes there (httpd trunk)
** if for some reason this work doesn't proceed fast enough for mod_fcg= id to be included in the next httpd release, it can be axed from the future= httpd 2.4/3.0/whatever branch when that branch is created
* use the htt= pd/mod_fcgid subtree for bug fix releases of mod_fcgid (retain compatibilit= y with httpd 2.0/2.2 as well as existing mod_fcgid configurations)

--000e0cd297f0a23bed046772f506--