On Fri, 16 Jun 2006, Geoffrey Young wrote:

>> But I wasn't saying "I'm going to release it, screw you."

> sure sounded that way, but ok.

I apologize. Note the question mark in the title of this thread. I thought
I was offering to help the mod_perl project, honestly.

>> I was saying "I'd like to release a bug-fixed version, because I have
>> no idea when mod_perl 1.30 will come out, if ever, but I can fix this
>> bug and release Apache::SizeLimit 0.04 right now."

> still, you think that would fly on p5p? the change list on mp1 is very

Yes, it would fly on p5p. I did it with Time::Local, for example. In fact,
p5p is very much in favor of dual-lifing modules, from what I can tell.
Making something dual-life from the Perl core is relatively matter-of-fact
these days. Heck, even very "internal-y" things like Threads.pm have been

> small, which is why there hasn't been a release in a while. and you're
> certainly capable of posting a patch and using CVS instead of
> maintaining a separate fork.

The reason I want to release this is because we use Apache::SizeLimit at
my day job. We're planning to open source our code eventually, and we
don't want to release a forked Apache::SizeLimit, obviously. That means
either getting a fixed version on CPAN or renaming our version to
Socialtext::Apache::SizeLimit. I think the former is better since it
benefits all mod_perl 1.x users.

Waiting for mod_perl 1.30 is really not an option. We can't have much
impact over when that will come out, and I don't think we'd want to make
that a prereq anyway. 1.29 is 2.5 years old, so pretty much every modern
distro has it available as package. 1.30, even if it came out tomorrow,
would be too new to make a prereq.

Telling people who go to install our app that they need to install
Apache::SizeLimit "plus some random patch" on our servers would be pretty
user-unfriendly. That's not how you make a nice install process for folks.

We want to say "you need mod_perl 1.29" plus Apache::SizeLimit 0.04, and
have them be able to get that stuff via packages and/or CPAN, just like
everything else.

> separation is, in fact, a good thing, whether we want to pull in the
> CPAN version on future releases, or drop it and confuse our userbase who
> thought they would be getting an update on the next release, etc.

Like I said, I'd be happy to provide patches back to the mod_perl folks
against what's in your tree. If a 1.30 is planned, I'd work with the
maintainer to make sure that Apache::SizeLimit in the tree was up to date
with what's on CPAN.

Frankly, I'm kind of insulted you'd think I'd make this a lot of work for
the maintainer. I think I have a pretty good history of being a good free
software citizen, especially in the Perl and mod_perl worlds. Please give
me some credit here.

> so, to that end, I'd suggest starting up a "hey, what do we do with
> Apache::SizeLimit and other modules that might benefit from a separate
> life on CPAN?" personally, it doesn't matter to me what the outcome is

No, let's not start that thread, please. I'm not proposing to maintain any
other modules, and I don't want to have an Apache::SizeLimit release gate
on a decision about every other module. I'm proposing something small,
simple, and doable in a short time frame.

If I do this and it inspires other people to come along and dual-life
something else, that'd be great, I think.

> so long as the main people responsible for managing releases agree. one
> thing for sure, though, I'd really prefer to see both mp1 and mp2
> supported in a single release if Apache::SizeLimit does have a new,
> separate life on CPAN...

What Philip said


/*================================================= ==
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
================================================== =*/