[removed dbi-users from the cc list for this bit]
Darren Duncan wrote:
First of all, what is the general policy regarding modules that are currently bundled with the core DBI distribution itself? Several on your list are:
DBD::DBM DBD::File DBI::PurePerl DBI::SQL::Nano
The above are part of DBI-1.43 and have been in DBI-N for awhile.
Those are all ones that I would describe myself as junior-co-maintainer. Tim makes the final decision on any changes to them. Basically, none of those modules is meant to ever change very much, they should stay pretty much as-is except for bug reports, simple yet powerful changes (e.g. possibly adding DBM::Deep support to DBD::DBM), and things needed to keep related modules happy (DBD::File and D:S:Nano work in conjunction with most of the other modules on my list as well as other modules). Oh, and helping migration to DBI v2, parrot, and etc.
I don't understand all the politics involved, but wouldn't these modules then be part of the maintenence group that includes DBI itself
At this point my role with those modules is basically to help field bug reports and test fixes. I'd see the project as working to assist in that process. The reason for including them in the project(at least all but DBI::PP, is that they intertwine with the other modules on my list).
how is it determined which externally-maintained but related modules make the cut to be bundled with DBI itself and which ones don't? While I understand some choices, others seem rather arbitrary.
DBI::PurePerl obviously needs to be part of DBI. The other three are there to support the next edition of _Programming the Perl DBI_ - we wanted people to be able to use the examples in early chapters of the book without installing anything other than the core DBI distribution itself. (Ok, not just for the book, this is a worthwhile goal in itself). The three modules are the bare minimum needed to accomplish that goal.
I vote for the PerlDB name myself.
Thanks for all your comments.
-- Jeff
