Re: DBD::MySQL

2013-06-28 Thread Michiel Beijen
Tux forwarded me this message, I'm now subscribed to dbi-dev@perl.org.

 -- Forwarded message --
 From: Martin J. Evans boh...@ntlworld.com
 To: dbi-dev@perl.org
 Cc: p...@patg.net, captt...@cpan.org, fr...@cpan.org, j...@cpan.org, 
 ran...@cpan.org, r...@cpan.org, robert.dod...@gmail.com
 Date: Fri, 28 Jun 2013 00:10:11 +0100
 Subject: Re: State of DBD::mysql maintenance

snip

 On 27/06/2013 22:22, Tim Bunce wrote:

 Then I looked at the RT queue for DBD::mysql
 https://rt.cpan.org/Public/Dist/Display.html?Name=DBD-mysql
 and felt sad at the apparent neglect. 127 bugs (7 critical)
 of which over half are still 'New'.

 and of those I see:

 o a load of supplied patches and many have been applied by MICHIELB to github
 o quite a number of duplicates
 o a few that look like they may be misunderstandings or errors on the part of 
 the reporter
 o 4 items marked as wishlist/enhancements - there are obviously more not 
 marked as such
 o some which seem to be fixed but not marked as such e.g. rt60085
 o 70+ rts over 2 year old

 It looks to me like a little house keeping and a new release would seriously 
 dent the queue.

I'm the MICHIELB that supplied some of the patches to github.
Patrick was very quick at merging them in DBD::mysql but the related
RTs are still open; for instance

https://github.com/CaptTofu/DBD-mysql/pull/43
https://rt.cpan.org/Public/Bug/Display.html?id=76462

I second that the RT queue definitely needs some love and that many of
the tickets can probably be closed easily.

snip

 I've no idea if the DBD::mysql maintainers need more help. When I was 
 actively using DBD::mysql (a lot of years ago) I supplied patches to Patrick 
 and they were applied. Not everyone is capable of supplying patches. I'm 
 guessing DBD::mysql is probably the most used DBD and as mysql is so easily 
 installed by most package managers I guessed a lot more inexperienced users 
 are using DBD::mysql and that might be leading to a load of wrong rts but the 
 last one rejected was 3 years ago.

 Three years ago (I think it was just after a LPW), I suggested having a DBD 
 team where DBD maintainers (and anyone else who was capable) could pitch in 
 to help keep the rt queues down - there wasn't much interest. I think I 
 repeated it again about 1 year ago with a similar result (although that may 
 have only been on irc). Now most DBDs are in git it should be a lot easier. I 
 also see around 25 people on #dbi regularly these days whereas 2 years ago it 
 was probably around 5, if that. I get a feeling there is a lot of potential 
 there if it can be stirred up a bit. I wish I could have attended the last QA 
 hackathon as I would have been happy to work on rt queues for any of the DBDs 
 I thought I could have helped with. I wonder if we could organise a DBI/DBD 
 hackathon even if it was one done remotely.

 Anyway, here is my offer to DBD maintainers and in particular DBD::mysql 
 maintainers.  If you want some help with rt queues in particular whether that 
 be simply some house keeping on the queue itself (I'd need privilege to do 
 that bit - cpan id MJEVANS) or bug finding/fixing I'm prepared to help out 
 where I can - just ask. For reasons I'm not going to go into here I will have 
 more spare time over the next month and the DBD::ODBC queue is almost non 
 existent and DBD::Oracle queue is almost under control so get it while you 
 can.

That would be very awesome; I'm sure Patrick can grant you access to
the RT queue (right??)

For me, I work for OTRS, we make open source helpdesk software. Our
software uses DBI and users can run it on different database backends,
using the power of DBI. Most of our users deploy on MySQL, but we
actually had most issues with DBD::ODBC (and I've had some
conversations on IRC and mailing lists with mje as a result of this).
I'm sure mje can be a major asset to the DBD::mysql maintenance.

But recently I ran into some issues with DBD::mysql which lead me to
send some of the pull requests to Patrick. I also promised him to fix
up more of the documentation of DBD::mysql regarding the installation,
but failed to do so, yet :(

I'd also be willing to help out fixing up some of the issues although
I do not have XS-skills (such as mje) and I have limited time,
nevertheless  DBI is a major component of our stack so it's also
important that it works well. Some kind of DBD bug squad sounds like a
very good idea in my opinion, I'd join in!
--
Mike


Re: State of DBD::mysql maintenance

2013-06-28 Thread Tim Bunce
On Fri, Jun 28, 2013 at 04:37:44AM -0400, Michiel Beijen wrote:
  From: Martin J. Evans boh...@ntlworld.com
 
  Anyway, here is my offer to DBD maintainers and in particular
  DBD::mysql maintainers.  If you want some help with rt queues in
  particular whether that be simply some house keeping on the queue
  itself (I'd need privilege to do that bit - cpan id MJEVANS) or bug
  finding/fixing I'm prepared to help out where I can - just ask.

That's great.

I can give you access for that Martin by making you a co-maint,
but naturally I'm reluctant to do so without the approval of the
current maintainers.

 I'd also be willing to help out fixing up some of the issues

Thanks for the offer Mike.

 although I do not have XS-skills (such as mje) and I have limited time,

We all have different skills to offer, and limited time, that's why
working together as a team is so effective.

I'd really like to hear from any of the current maintainers.

I'd also specifically like to ask if they'd be happy to move the repo
under the umbrella of the github perl5-dbi organization
https://github.com/perl5-dbi where many people would be able
to help directly.

Tim.


[perl5-dbi/dbi] 655e23: schema part is optional

2013-06-28 Thread H.Merijn Brand - Tux
  Branch: refs/heads/master
  Home:   https://github.com/perl5-dbi/dbi
  Commit: 655e2375ba089f798ec727360db214630aca9c7b
  
https://github.com/perl5-dbi/dbi/commit/655e2375ba089f798ec727360db214630aca9c7b
  Author: H.Merijn Brand - Tux h.m.br...@xs4all.nl
  Date:   2013-06-25 (Tue, 25 Jun 2013)

  Changed paths:
M t/51dbm_file.t

  Log Message:
  ---
  schema part is optional