request to become co-maintainer of DBD::SQLite
Darren Duncan
I would like to request your permission or blessing to become an official
co-maintainer of the DBD::SQLite module, which is the defacto standard binding
for SQLite to Perl.
(Also CC'd are some other concerned parties as FYI; my apologies if I've written
too many people. But this message is initially just for response by Matt,
though others can write if they feel inclined, but try to keep the recipient
list smaller than I just did here. Focus any discussion to dbi...@perl.org and
mod...@perl.org as appropriate please, the former for what work needs doing and
the latter for matters of module maintainership.)
P.S. Or if anyone else has the tuits and wants to make a better offer to be a
co-maintainer now, please do so.
I am interested in the long-term success of SQLite in combination with Perl, and
in the short term I am particularly interested in using the latest SQLite 3.6.8
(which adds the extremely important feature of nested transactions) with modern
versions of Perl, and I am interested that it would be easy for the large number
of other DBD::SQLite users to use this combination as well.
I am also concerned with there apparently being a number of significant bugs in
DBD::SQLite that have been reported on the RT system, some with patches, and
DBD::SQLite hasn't seen new releases in awhile to either address bugs or update
the bundled SQLite. A number of people I trust are seeing that this is a
serious matter to address, some in the mean-time recommending use of older
DBD::SQLite versions, which is itself a problem since automatic CPAN install
tools would select the newest versions, and access to newer SQLite library
features is missing.
Now I would of course be happiest if you had the time and motivation to bring
your project up to date and address its bugs. But otherwise I would like to
offer you an out, and take on this responsibility myself, either alone or with
partners such as yourself or other concerned parties that want to help.
If you agree, then please say the word to mod...@perl.org.
My CPAN account ID is DUNCAND.
To summarize, this is my intention in the short term:
1. Release a new version every time there is a SQLite core library release.
2. Make only the most minimal changes to DBD::SQLite itself, to ensure that
reported bugs are fixed and that it compiles on modern systems and passes its
own test suite on the same. There won't be any feature additions or
architectural changes initially, except where such may be highly demanded and
simple. The priorities here are stability and correctness plus easy access to
all the SQLite library's native features, and minimal additional features.
3. All initial releases will have version numbers ending in _NN that mark them
as developer releases, so the community can test them before they become what
the CPAN tools install by default.
4. Perhaps follow what Audrey Tang started and use the official amalgamated
pre-compiled source files rather than the original-original source code, so
users with less capable build environments can handle it. Though in the short
term this will depend on which version I can get to work with fewer problems on
my own machine (Mac OS X Leopard).
5. I may use an older DBD::SQLite than the current one, such as 1.12, as an
initial point of departure, if doing so makes for a more trouble-free solution.
6. I will have this in a public GIT source repository and I will regularly seek
feedback, help, patches, testing, etc from the user community that have a stake
in this working.
7. I am assuming until corrected that the primary discussion forum for people
to discuss actual work to do and patches etc for DBD::SQLite is dbi...@perl.org.
Some caveats:
1. I have very little C-fu right now and won't be able to do much in the short
term besides update the SQLite source files, and apply third-party patches to
the C, and make more involved fixes to the portions written in Perl.
2. It will probably be several weeks before my first release, partly because I
am busy with other tasks and I also need time for feedback and discussion.
3. All my releases should be considered experimental until further notice,
after a significant body of users has put them through the ringer and considered
them GA quality.
4. I *will* require third parties to submit patches to bugs in the C code in
order for many relevant problems to be fixed. I may be able to fix some
problems myself, but otherwise I call it a division of labour, and my part is
mainly about applying patches and doing the releases; others can do a lot of the
actual fix patch making. Generally speaking, the bugs that get fixed are the
ones people send me patches for.
5. In general I will not ever be working with blead of the core SQLite library,
only its public releases, which have a thorough test suite of their own.
6. One of my first code changes will be to require DBI 1.607+ and Perl 5.8.1+
(and the former requires the latter too), though I may only ever run it under
5.10.x on my machine. But if anyone knows that it will work with older
versions, they can submit a patch to that effect.
7. I would also like to adopt the versioning scheme that Audrey Tang used, so
that for example a first stable release with the current SQLite would be
DBD::SQLite 3.6.8.0, with the last digit only being updated while updates to
DBD::SQLite itself occur but updates to SQLite itself don't. One question I
still have to figure out though is whether that can be done in combination with
the _NN suffix to mark developer releases, eg as 3.6.8_0 or 3.6.8.0_0 etc, so
that CPAN install tools work, and nothing on CPAN/PAUSE/etc would break.
Presumably I'd add a dependency on version.pm (bundled with Perl 5.10.x) in any
event. The main benefit of this versioning scheme is that it is easy for users
to know at a glance what they're getting, and also if for some reason users need
me to later bundle some older SQLite version, the space already exists for
appropriate lower version numbers.
Basically I'm doing this because someone has to do it, and I'm as good a default
person as any until someone better suited (eg, with more C-fu) comes along and
takes my place.
Matt, thank you in advance for a quick reply.
To everyone, please don't actually submit patches to me until I announce that
I'm ready to receive them, or just send them to RT as you already were.
-- Darren Duncan