httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: mod_fcgid support
Date Thu, 16 Apr 2009 16:27:58 GMT
William A. Rowe, Jr. wrote:

> Chris, I'm really confused.  Are you asking to branch httpd trunk into
> a 2.4 branch (bad, we aren't there) or a 2.3 branch (overkill IMHO, if
> we don't have cycles to get to 2.4/3.0 with what's in trunk, we certainly
> don't have cycles to make the determinations of what is in 2.4 vs 3.0).

   Sorry, neither -- it's confusing because mod_fcgid's last released
version was 2.2, so any discussion about subsequent releases (completely
independent from httpd development) naturally leads to talk of 2.3/2.4/etc.
version numbers.  So there's a confusing but coincidental overlap between
the version numbers in play here.

   Basically my question boils down to this: do we work first on moving
mod_fcgid into httpd trunk, or work on it first as a standalone product?

> Or asking for an fcgid branch?  You can do whatever you like in the sandbox
> including preparing a 2.2 or 2.0 flavor from the initial import.  (To then
> release it requires a vote of the PMC, of course).

   Yes, I was asking about a mod_fcgid branch (named 2.x, I guess).
More on that below.


Jeff Trawick wrote:

> * 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

   This would be ideal.  The steps to move forward here are
obvious and straightforward, I think.

> * 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)

   I see where you're going with this, and I like it.  It means
that for the time being, we just ignore the incomplete autoconf/build
stuff in mod_fcgid's sandbox.

   Going forward, if we feel we have a useful codebase in httpd
trunk's mod_fcgid module that we want to release independently,
we backport it as necessary to make it compatible with existing
standalone mod_fcgid configurations (likely mostly renaming config
directives back to their old names, etc.), deal creating a proper build
framework for an independent mod_fcgid (if, indeed, that's needed
at all), and vote on a release.  But since we might not even do
any of this, no need to start on this work first.

   OK, that helps a lot.  Sorry to get hung up on these "process" issues.
If no one else has comments, I think proceeding down the road Jeff
outlined is the way forward.  Thanks,

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B


Mime
View raw message