My only suggestion at the moment, please use the amalgamation instead of individual files. This makes it much easier to upgrade when SQLite releases a new version.
g -----Original Message----- From: Clark Christensen [mailto:cdcmi...@yahoo.com] Sent: Wednesday, January 14, 2009 10:19 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] request to become co-maintainer of DBD::SQLite > One of my first code changes will be to require DBI 1.607+ The current DBD-SQLite works fine under older versions of DBI. So unless there's a compelling reason to do it, I would prefer you not make what seems like an arbitrary requirement. Otherwise, it sounds like a good start. Matt must be really busy with other work. I'll be happy to contribute where I can, but no C-fu here, either :-( -Clark ----- Original Message ---- From: Darren Duncan <dar...@darrenduncan.net> To: m...@sergeant.org; mserge...@cpan.org Cc: General Discussion of SQLite Database <sqlite-users@sqlite.org>; DBI Dev <dbi-...@perl.org>; DBIx::Class user and developer list <dbix-cl...@lists.scsys.co.uk>; rose-db-obj...@googlegroups.com; modu...@perl.org; c...@audreyt.org Sent: Tuesday, January 13, 2009 7:55:30 PM Subject: [sqlite] request to become co-maintainer of DBD::SQLite 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-...@perl.org and modu...@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 modu...@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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
