Re: release canditates

Philip M. Gollucci wrote: Hi, I'd like to propose the following change to make rolling release candidates slightly easier. Instead of removing the -dev in ./Changes, we could change it to rc1, rc2, etc. The version would then be 'mod_perl-2.0.x-rcn' and the tarball would be mod_perl-2.

Old versions

Your friendly neighborhood reminder: 10. Old Versions Remind other Developers to delete versions older then the prior release from CPAN. Old releases can always be found on BackPan. -- END What doesn't kill us can only ma

release canditates

Hi, I'd like to propose the following change to make rolling release candidates slightly easier. Instead of removing the -dev in ./Changes, we could change it to rc1, rc2, etc. The version would then be 'mod_perl-2.0.x-rcn' and the tarball would be mod_perl-2.0.x-rcn.tar.gz which untars

Possible improvements for module reloading

Hi, I'm using following patch with mod_perl2 in my developing environment. This might be helpful for others, but I'm not sure this will break something in the environment with another configuration. (1) With prefork MPM, fixup %INC variable to be stored as absolute path after eval(). This c

Re: the multiple messages over the same connection case

I suppose the only solution is to merge the modperl dev list and mailchannels dev list into one. I keep on screwing up :( -- _ Stas Bekman mailto:[EMAIL PROTECTED] http://stason.org/ MailChannels: Assured Messaging(TM) http://mailchann

the multiple messages over the same connection case

I'm trying to figure out what's the best way to handle multiple messages over the same connection case, since it looks like we may have a problem with. So first of all the access logging. Should we commit the log at the end of EOM? (and also try in the handler in case EOM wasn't reached) At t