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

[Goro Fuji]

Hello Darren Duncan,

Just now I am concidering to maintain DBD::SQLite, and I have ideas about that:
(1) to separate SQLite from DBD::SQLite (not to be bundled), which
will also separate ploblems of SQLite from those of DBD::SQLite.
(2) to make a new module Alien::SQLite (see other Alien::* modules),
which will allow different versions of SQLite.
(3) to allow "use DBD::SQLite 1.15 -sqlite_version => q(3.6.8)" for testing.

What do you think of it?

Regards,
-- 
Goro Fuji (gfx)

2009/1/14 Darren Duncan <darren at darrenduncan.net>:
> 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
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>