Re: SQL::Statement unusable in major Linux distributions

[Paul Beardsell <paul@beardsell.com>]

Jonathan,

You are looking at this from a most Debian-centric POV.  There are 100 distros.  OK, there are only 20 popular ones, only 5 notable ones and only 1 great one :-) but perhaps if I phrased it thus:

"The discoverer of a NON-DISTRO SPECIFIC bug cannot be responsible for contacting EACH distro."

If I'm working on a Perl app on some other non-Debian distro and the bug I discover is pretty obviously not distro-specific then are you suggesting I report it to Debian?  If so are you suggesting I report it also to Suse, RH, Ubuntu etc?  No.  The place to report it is to that distro's bug tracking system (if they have one) and rt.cpan.org.  If I don't report it to CPAN how will Debian ever get to know of the bug?

If I find a bug in a four year old version of a package but that is the current version that is distributed in every Linux distro then there needs to be a central place for the bug report.  Where is that?  It is rt.cpan.org.  And I believe RT admin agrees (on this narrow point, at least). That's the position we are in with SQL::Statement

This bug I have reported to Ubuntu via Launchpad.  At the moment I have not reported it formally to Debian as I temporarily only have Woody because that's the last Debian with a working libsql-statement-perl i.e. SQL::Statement 0.1020.  I have verified it on Etch and Lenny but that machine is dead so I cannot report version numbers etc exactly.  I have reported it to CPAN for the benefit of everyone.  And so the package maintainer can consider if it applies to the latest version of the package.  It does and therefore, as it is such a critical bug, the package should perhaps not be accepted by Debian.  But it has been!  A few days before my bug report.  And had I not been so tenacious the bug report would have remained "rejected" or "deleted", not "open", and you would not know of it.  Ever.  After a while you would stop including libsql-statement-perl in Debian because NOBODY uses it BECAUSE IT IS UNUSABLE by anyone who wants a simple SQL UPDATE statement to work.  

There is a lot of excellent code available from CPAN from a lot of most dedicated developers/maintainers and testers and documenters and, dare I say, bug reporters!  Thanks to any of you who read this.  However, it is *not* ALL of excellent quality, and being shy of saying so can be part of the problem.  That doesn't mean to say that some packages are more challenging than others to maintain.  Some maintainers have bravely taken on packages which are in a mess and which need lots of work.  Some maintainers have an easy life!  Others slog their guts out for no thanks.  And in their spare time.  But the quality of the packages and their maintenance does vary, package to package.

Paul Beardsell

2009/11/4 Jonathan Yu <jonathan.i.yu@gmail.com>

Hi Paul:

>From the perspective of Debian in particular, I have the following
statement to make.

On Tue, Nov 3, 2009 at 5:49 PM, Paul Beardsell <paul@beardsell.com> wrote:

[snip]

>
> * It is beneficial to the Perl community (developers and users) that bugs
> are held centrally. I am sure this is also the position of the Perl
> community. The discoverer of a bug cannot be responsible for contacting each
> distro.  Distro maintainers cannot independently triage *all* bugs in all
> the packages they include.  They need (we need!) "upstream", a central
> repository.  rt.cpan.org has the facility to record bugs against older but
> still current versions.  It should be used as I think Jesse Vincent also
> intended, for the benefit of the wider community, as this central
> repository.
>

[snip]

In Debian, we like to have everything that affects our packages filed
in our bug tracker (the Debian Bug Tracking System). From time to time
in the past, we have missed these bugs (ie, not forwarded them
upstream), and this has been problematic for people. However, our bug
tracker is entirely open and anyone is free to look at our packages
and forward relevant issues upstream.

One particular point I'd like to make is that sometimes bugs only
exist downstream due to some modifications we've made in order to
package things or for some other reason. As a result, it doesn't seem
fair to bother the upstream maintainers about issues which are
Debian-specific, or Fedora-specific, for example.

Therefore, we ask that our users always file bugs against the Debian
packages; we will coordinate with upstream appropriately to get things
fixed, taking care to forward the bug and make whatever arrangements
necessary to fix the package.

In general, the CPAN Request Tracker has been where we forward most of
our bug reports. Some maintainers do not like to use the RT system,
and we have to respect their wishes. In that case, we file bugs by
whatever means the maintainers tell us to in the POD of their
packages, or otherwise in the RT or via direct mail.

In defense of the SQL::Statement maintainers and all, I think if there
are critical issues with older releases, they should be brought to the
attention of each distro. Debian has policies for when things get
synchronized between unstable <-> testing, and things that can be
updated in stable. Things like security fixes and critical fixes are
candidates for patches in stable, however this is the responsibility
of Debian/Fedora/etc and not of the CPAN Maintainers.

I urge you to let the CPAN maintainers do what they do best -- produce
good software. Others (including those that package these modules) are
responsible for distro-specific issues, and I encourage you to file
bugs in those packages.

Cheers,

Jonathan