You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2009/02/11 22:01:31 UTC
Re: [summary] accept mod_fcgid codebase into httpd project
On Jan 27, 2009, at 9:44 AM, Chris Darroch wrote:
>> The httpd-mod_fcgid.xml file is my first whack at the IP clearance
>> template.
>
> I renamed this .xml.utf8 this morning because I realized it has some
> non-ASCII UTF-8 character sequences in it. I don't know if those will
> pass through the Incubator's XML-to-HTML transformation smoothly;
> if not,
> they could probably be removed.
I ended up fixing all website generation to utf-8 -- I am surprised
that it lasted this long with just iso-8859-1.
>> 4) The code package is a checkout of the CVS trunk from SourceForge;
>> all I've done is insert LICENSE and NOTICE files, add AL 2.0
>> license
>> text to all .c, .h, .rc, and .mk files (following the httpd
>> example)
>> and prune out some small text and CVS files.
>
> Assuming the Incubator IP clearance review passes, I'd suggest that
> we import the code into SVN by starting not with this temporary
> package,
> but with a cvs2svn export of the SourceForge commit history. The
> relicensing can then follow as a single subsequent commit. Sound OK?
Yes, that is what I prefer as well. All paperwork is done, so please
let us know when you have an export. I (or one of the other svnadmins)
will have to massage it a bit to prefix the sourceforge ids, so just
point us to the dump file when you have it ready.
....Roy
Re: [summary] accept mod_fcgid codebase into httpd project
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Roy T. Fielding wrote:
> I ended up fixing all website generation to utf-8 -- I am surprised
> that it lasted this long with just iso-8859-1.
Thanks -- looks good!
> Yes, that is what I prefer as well. All paperwork is done, so please
> let us know when you have an export. I (or one of the other svnadmins)
> will have to massage it a bit to prefix the sourceforge ids, so just
> point us to the dump file when you have it ready.
I'll tackle this next week, if tomorrow's not possible. Thanks
very much,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Roy T. Fielding wrote:
> I think most of the stuff in NOTICE is documentation that belongs
> in README. The only things we put in NOTICE files are copyright
> or attribution lines required by the original copyright owners.
OK, thanks -- made a quick edit this morning.
> Makefile and .deps should be generated files.
Agreed; I haven't removed .deps yet because the existing build
process fails without it. If we're moving into httpd's modules
collection, all this stuff can be scrubbed. If we're distributing
separately, the module will need a full autoconf implementation.
I'm +1 on the former idea as it saves a lot of effort. :-)
> We have not done any releases of this code, so we are not responsible
> for "fixing" releases that might already exist. In any case, a branch
> can be created at any time by copying a specific revision number; there
> is no reason to create it before the branch is needed.
True; I just figured this might count as part of dotting all the i's,
etc. Happy to skip it if not needed.
> Go ahead. It might be worthwhile to create a tag after the whitespace
> changes (same as a branch but without implying later mods) that we can
> use for easier functional diffs in the future.
Done and done, I think.
> FCGI_ is good. What about docs?
Docs will take some time, as they always do. Ryan's original
English docs, which are fairly terse, remain on his fastcgi.coremail.cn
site. I think it's probably worth taking the time to write a fresh
set and one that covers all the more recent configuration directives.
Again, this would be a lot easier to do within the existing httpd
doc build framework (even if the docs aren't actually committed until
the code migrates too), so I'm inclined to wait for an agreement on
whether that's the general plan before diving in. Opinions?
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
mod_fcgid
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 17, 2009, at 3:44 PM, Chris Darroch wrote:
> Roy T. Fielding wrote:
>
>> Done. I set all of Ryan Pan's commits to svn:author=pqf
>> (for consistency), loaded the whole thing under httpd/mod_fcgid
>> and fixed the eol-style to native.
>>
>> Please relicense the directory and files first before making any
>> other changes.
>
> Thanks! I think the relicensing is all done; anyone who wants
> to check for errors will get a thank-you.
I think most of the stuff in NOTICE is documentation that belongs
in README. The only things we put in NOTICE files are copyright
or attribution lines required by the original copyright owners.
>> After that, we should remove the generated artifacts
>> and consider moving the subdirectory to a module dir under the
>> server trunk.
>
> Which artifacts are you concerned about? I'm not 100% sure
> what you'd like done here.
Makefile and .deps should be generated files.
> I'm +1 on the idea of moving toward inclusion in httpd trunk
> as a module, at least as a longer-term goal. My thoughts were:
>
> - Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on
> the current relicensed code, just in case an "emergency" turns up
> (security bug?) and we'd like to do a release based on the existing
> code; most likely, we won't use this going forward.
We have not done any releases of this code, so we are not responsible
for "fixing" releases that might already exist. In any case, a branch
can be created at any time by copying a specific revision number; there
is no reason to create it before the branch is needed.
> - Fix the whitespace; currently if you set your tab stops to 4 chars
> it looks "right" and close to the httpd style, so it's just a
> conversion from tabs to spaces that remains. I've got a reformatted
> version ready to commit.
Go ahead. It might be worthwhile to create a tag after the whitespace
changes (same as a branch but without implying later mods) that we can
use for easier functional diffs in the future.
> - Before we can add to httpd trunk, we need to look at the directive
> names. There are a large number of config directives with names
> that don't imply FastCGI and in some cases are a little mysterious.
> I don't think we can drop 32 new directives into httpd with generic
> names like "SocketPath" and "PassHeader".
>
> I have an old patch I can dust off to rename these; we should choose
> a prefix first, though. "FCGI" or "FastCGI"? The latter might
> conflict with mod_fastcgi, but then, why would anyone run both at
> the same time? Still, perhaps "FCGI" is best?
FCGI_ is good. What about docs?
....Roy
Re: [summary] accept mod_fcgid codebase into httpd project
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 17, 2009 at 6:44 PM, Chris Darroch <ch...@pearsoncmg.com>wrote:
>
> I'm +1 on the idea of moving toward inclusion in httpd trunk
> as a module, at least as a longer-term goal. My thoughts were:
>
> - Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on
> the current relicensed code, just in case an "emergency" turns up
> (security bug?) and we'd like to do a release based on the existing
> code; most likely, we won't use this going forward.
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."
(But of course we should include in httpd trunk for Apache 2.4 and beyond,
and make any appropriate changes for consistency, new directions, etc.)
- Before we can add to httpd trunk, we need to look at the directive
> names. There are a large number of config directives with names
> that don't imply FastCGI and in some cases are a little mysterious.
> I don't think we can drop 32 new directives into httpd with generic
> names like "SocketPath" and "PassHeader".
Trunk is a fine place to address those issues.
BTW, thanks for all your work on this!!!
Re: [summary] accept mod_fcgid codebase into httpd project
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Roy T. Fielding wrote:
> Done. I set all of Ryan Pan's commits to svn:author=pqf
> (for consistency), loaded the whole thing under httpd/mod_fcgid
> and fixed the eol-style to native.
>
> Please relicense the directory and files first before making any
> other changes.
Thanks! I think the relicensing is all done; anyone who wants
to check for errors will get a thank-you.
> After that, we should remove the generated artifacts
> and consider moving the subdirectory to a module dir under the
> server trunk.
Which artifacts are you concerned about? I'm not 100% sure
what you'd like done here.
I'm +1 on the idea of moving toward inclusion in httpd trunk
as a module, at least as a longer-term goal. My thoughts were:
- Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on
the current relicensed code, just in case an "emergency" turns up
(security bug?) and we'd like to do a release based on the existing
code; most likely, we won't use this going forward.
- Fix the whitespace; currently if you set your tab stops to 4 chars
it looks "right" and close to the httpd style, so it's just a
conversion from tabs to spaces that remains. I've got a reformatted
version ready to commit.
- Before we can add to httpd trunk, we need to look at the directive
names. There are a large number of config directives with names
that don't imply FastCGI and in some cases are a little mysterious.
I don't think we can drop 32 new directives into httpd with generic
names like "SocketPath" and "PassHeader".
I have an old patch I can dust off to rename these; we should choose
a prefix first, though. "FCGI" or "FastCGI"? The latter might
conflict with mod_fastcgi, but then, why would anyone run both at
the same time? Still, perhaps "FCGI" is best?
As for the names themselves, I (natch) have a few suggestions which
I think clarify the purpose of some of the more obscure ones and
align them with other httpd modules a bit. E.g.,
DefaultMinClassProcessCount might become FCGIKeepServersPerScript
or just FCGIKeep since it resembles mod_dbd's DBDKeep in its
purpose.
I'd like to branch and apply whitespace changes fairly soon;
if folks think that's the wrong approach or if there errors in the
newly-applied license text, please let me know! Cheers,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 18, 2009, at 1:13 PM, Chris Darroch wrote:
> Roy T. Fielding wrote:
>
>>> I'd suggest that we import the code into SVN by starting not
>>> with this temporary package, but with a cvs2svn export of the
>>> SourceForge commit history. The relicensing can then follow as
>>> a single subsequent commit. Sound OK?
>
>> Yes, that is what I prefer as well. All paperwork is done, so please
>> let us know when you have an export. I (or one of the other
>> svnadmins)
>> will have to massage it a bit to prefix the sourceforge ids, so just
>> point us to the dump file when you have it ready.
>
> It should be in people.apache.org:/home/chrisd/donations/
> mod_fcgid now.
>
> I used the default "full" cvs2svn conversion; if you want one
> with just
> the trunk and without the small number of CVS tags in the mod_fcgid
> repository, let me know. There weren't any branches or anything too
> complex in the SF repository.
Done. I set all of Ryan Pan's commits to svn:author=pqf
(for consistency), loaded the whole thing under httpd/mod_fcgid
and fixed the eol-style to native.
Please relicense the directory and files first before making any
other changes. After that, we should remove the generated artifacts
and consider moving the subdirectory to a module dir under the
server trunk.
....Roy
Re: [summary] accept mod_fcgid codebase into httpd project
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Chris Darroch wrote:
> Roy T. Fielding wrote:
>
>> Yes, that is what I prefer as well. All paperwork is done, so please
>> let us know when you have an export. I (or one of the other svnadmins)
>> will have to massage it a bit to prefix the sourceforge ids, so just
>> point us to the dump file when you have it ready.
>
> It should be in people.apache.org:/home/chrisd/donations/mod_fcgid now.
>
> I used the default "full" cvs2svn conversion; if you want one with just
> the trunk and without the small number of CVS tags in the mod_fcgid
> repository, let me know. There weren't any branches or anything too
> complex in the SF repository.
Sorry not to follow up on this for a while; been busy with other
stuff. Is there anything else I can help with here? I'd be happy to
tackle munging IDs if someone can provide a quick tutorial on what's
needed.
I should probably also ask about setting up mailing lists,
a Bugzilla entry, and getting Web site mojo for mod_fcgid. It would
be good to have stuff up and running so we can let people on the old
SourceForge mailing lists know about the adoption, among other things.
Once the code's in SVN I figured I'd try to do the following:
- apply license changes
- create legacy 2.x branch
- apply whitespace changes to match httpd standard
- begin applying functional patches
Thoughts?
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Roy T. Fielding wrote:
>> I'd suggest that we import the code into SVN by starting not
>> with this temporary package, but with a cvs2svn export of the
>> SourceForge commit history. The relicensing can then follow as
>> a single subsequent commit. Sound OK?
> Yes, that is what I prefer as well. All paperwork is done, so please
> let us know when you have an export. I (or one of the other svnadmins)
> will have to massage it a bit to prefix the sourceforge ids, so just
> point us to the dump file when you have it ready.
It should be in people.apache.org:/home/chrisd/donations/mod_fcgid now.
I used the default "full" cvs2svn conversion; if you want one with just
the trunk and without the small number of CVS tags in the mod_fcgid
repository, let me know. There weren't any branches or anything too
complex in the SF repository.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B