[Dbix-class] request to become co-maintainer of DBD::SQLite

[Darren Duncan]

Hello Matt Sergeant,

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-dev at perl.org and 
modules at 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 modules at 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-dev at 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