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
