Re: RFC: developing DBD::SQLite

David, thanks for your quick response.

David E. Wheeler wrote:
 > You *really* need to get Matt to signoff on this, IMHO.

I have tried emailing Matt several times without response already.  Should I try 
telephoning him next?  For all it looks like, Matt has abandoned the module.  If 
someone knows better, or has been in contact recently, I'd be happy to hear.

So following your response, I will eliminate a lot of the change items from my 
plan.  In particular, I will continue to bundle the SQLite library as it has 
always been done, and won't download anything.  I will also not add the 
version.pm dependency and will continue numbering releases where Matt left off, 
such as starting at version 1.15 or jumping up a bit and starting at 1.20_01 
which should be harmless.

In regards to which version to use, I will also leave that behaviour as Matt had 
it; his version could either use the bundled version or the system version, and 
I'll leave selecting which to the same mechanism Matt had it, unless the users 
argue for a change.  I think that means the bundled is the default.

So then, what I'm planning to do is this then:

1.  Enter DBD::SQLite into public version control using Git, with the initial 
version being the last one Matt published on CPAN, and then I will merge in 
Audrey Tang's changes that were released as DBD::SQLite::Amalgamation; 
essentially there is no change but that several dozen SQLite library files are 
replaced with a single one.

2.  Then I'll update the library to the latest one on sqlite.org, and then 
retest and deal with anything that breaks.

3.  Then I'll look at various open RT items and apply various submitted bug 
fixes, again testing.  And I'll accept collaborative fixes from other people 
such as those made against the version control.

4.  Then I'll put an experimental-versioned release on CPAN.

In fact, despite the larger sized releases, this probably is actually much less 
work for me when it comes down to it due to less complexity.  I really will just 
make the minimal changes possible from Matt's version, just to get it to run 
with the current SQLite library, which will now be the single amalgamation file. 
  Also mainly the driver would just be tested and asserted by me to work with 
the version of SQLite bundled with it.

And if users replace the bundled amalgamation file with a different amalgamation 
file, generally it'll act as if the replacement was the original, so this isn't 
really a separate case.

Now I know you said prefer system, but to start I'll just leave it the way Matt 
had it; mind you, if there is a general consensus to change this default, I'll 
honor it.

And my current plans are now back to what they were earlier this year when I 
proposed co-maintaining the driver, a focus on minimalism, before I became more 
ambitious in today's first proposal.

To conclude, I would be quite happy to not have this responsibility.  I am doing 
this primarily because I want SQLite to continue to succeed in the Perl world 
and no one is keeping the bindings up to date anymore, despite many people 
asking for updates.  I'm doing it because no one else is.  Now if Matt comes out 
of the shadows and addresses the languishing driver bug reports and updates the 
library to the new one, and continues to do so, I'm the happiest, but so far he 
isn't.  And my email attempts have failed at a response.

So, should I try to phone Matt now?

Thank you. -- Darren Duncan