[sane-devel] [RFC] Why I consider downstream bug reports a good thing

Paul Menzel paulepanter at users.sourceforge.net
Mon Feb 18 14:09:27 UTC 2013

Dear SANE folks,

Allan wrote in his reply to my message on the mailing list that he
considers downstream reports “pointless” [1].

Here are my arguments why I consider downstream reports good in addition
to upstream reports. Comments are welcome.

1. Distributions have different issues to deal with than upstream and
different rules. Basically they often cannot just ship the latest
upstream version.

Often they have several releases and depending on their focus they need
to add support for new hardware to older releases. Sometimes their
development guide lines prohibit to just ship new releases as code
cleanups or other improvements might be not allowed and only bug fixes
and hardware support is.

This is true for example for Debian stable releases, for Ubuntu LTS
(long-term support) releases or for example Red Hat Enterprise products.

As SANE upstream does not provide any LTS releases as for example the
Linux kernel, the distributions need to backport commits and they need
to know what needs to be backported. Package maintainers often do not
have much time for going through upstream log and need to know what
needs backporting. Downstream reports help them.

2. Having downstream reports shows the distribution’s quality assurance
team analyzing their bug tracking system where problems are. For example
if Red Hat, SUSE or Canonical [2] see that SANE issues make up five
percents (just made up) of the reports, they might decide to invest some
resources into upstream SANE. Either by assigning developers to work on
SANE by fixing bugs, improve code and to add support for new devices, by
contacting the device manufacturers and negotiate with them to provide
SANE drivers, or by simply paying developers.

3. Distributions often use their bug trackers – Debian the Debian BTS
[3] – to figure out their current state and their bug tracking system is
tightly integrated with their tools. Upstream integration means most of
the time just to document the upstream report and link to it, which is
important as that is how the WWW works.

4. Some distributions do not have a committed maintainer for SANE
packages, so uploads and packaging has to be done by packagers not
really familiar with SANE. Having downstream reports helps them to
improve the packaging.

Distributions with committed package maintainers mostly will not be
burdened by downstream reports, as they provide packages resembling the
upstream state regarding device support, so users will not hit these
issues and therefore will not report them.

5. Noting the URL of the downstream report in the upstream bug tracker –
Alioth in SANE’s case – is important to, to notify people, finding the
upstream report first, this bug is already tracked in their
distribution. And as written above, that is how the Web works. Links,
links, links.



[1] http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/030914.html
[2] https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bugs
[3] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sane-backends
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130218/2d9c1ad8/attachment.pgp>

More information about the sane-devel mailing list