SQL::Statement unusable in major Linux distributions

Paul Beardsell paul at beardsell.com
Wed Nov 4 02:34:20 UTC 2009


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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20091104/ada95ec1/attachment.htm>


More information about the pkg-perl-maintainers mailing list