Re: Ima::DBI patch for mod_perl compatibility

[prev] [thread] [next] [Date index for 2005/06/10]

On Fri, Jun 10, 2005 at 02:09:34PM -0500, Jason Gessner wrote:
> Anyone correct me if the argument i am posting is incorrect.

You're correctly restating what several people have said (and adding
some bits of your own). You're also ignoring what I have said.

> the way things look (from an observer like myself) is that you have  
> set in stone what C::DBI is, so we can all just deal.

In this specific case:

I've said numerous times I'm persuadable. I just haven't been persuaded
yet. Repeatedly saying the same things won't actually persuade me. I've
also said that even if I don't accept it, I'll gladly put effort into
making it as easy as possible for it to exist in another format. 

In the more general case:

Much as I'm a fan of the wiki approach to other things, I'm not yet
persuaded it works for software, and even less persuaded it works for
software that acts as infrastructure. At the minute I *do* decide what
goes in and what doesn't. That's just the way it is. 

There have been patches I've rejected before, and no doubt there will be
patches I'll reject in the future. 

As I've said before, I see Class::DBI as a project that will 'close'
for features at some point. My main goal is to facilitate people adding
whatever features they want in a non-invasive manner, and releasing
these as extras for other people's benefits, not as deciding whether
suggestions should or shouldn't be core functionality. Going forward
I expect to be removing more things from Class::DBI than I add. [1]

I see all of this as a Good Thing(tm), not a Bad Thing(tm). 

Tony


[1] For the avoidance of doubt, when I start removing core things, I
expect that I'll release a Class::DBI::Classic, or some such, that comes
pre set-up to work just like the current version. And I'll almost
certainly do it in a way that allows for a staged switch, whereby one
version will have the modules shipped and switched on by default, but if
they're not explicitly activated by the user then there'll be a warning
saying that this behaviour is deprecated. Then the next release will
have them shipped, but turned off. And the next will not ship them.
It's certainly not my intention for someone to move up one version of
Class::DBI and have lots of things break. These things move slowly.
There are still things in the last release that were deprecated 3 years
ago...