Re: SQL::Statement unusable in major Linux distributions
2009/11/4 H.Merijn Brand <email@example.com>:
> On Tue, 3 Nov 2009 19:04:23 -0500, Jonathan Yu
> <firstname.lastname@example.org> wrote:
>> 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 <email@example.com> wrote:
>> > * 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.
>> 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.
> Thanks for sharing your clear views from the Debian point of view, and I
> I wholeheartedly agree. Not only for perl Modules but also for the CORE,
> and I know things have been (very) bad in the past (in both directions)
> regarding up-/downstream changes to perl. Things have improved though.
Here I fully agree. Not only as SQL::Statement maintainer, but as packager
in pkgsrc, too. It's not always easy to report bugs upstream, and more: not
each developer/packager of a module has the appropriate test environment
the reporter has. That's why I always ask for easy, small tests (as you provide
them to me always - and I'm very thankful for them).
Even more useful is the filter functionality of the distribution bug
upstream forwarding: it fills the bugs more carefully. In fact - I
like to use it,
even on NetBSD (my favorite distribution) as committer. If I encounter a problem
I cannot solve on my own, I'm going to find a responsible committer and ask
him for help transporting the issue upstream - and maybe, applying a fix into
the packaging system until the next release is delivered.
I think Debian is making a good job there (I have several Linux distributions
on some test boxes running once all 3 month - and Debian costs me less
effort of all).