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

[Paul Menzel]

Dear Stef,


Am Montag, den 18.02.2013, 17:54 +0100 schrieb Stef:
> On 18/02/2013 15:09, Paul Menzel wrote:

> > 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.
> >
> >
> > Thanks,
> >
> > Paul
> >
> >
> > [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

> I suppose it's up to distro to tell if such feature requests help them. 
> Regarding SANE, Id' rather stick to 
> http://www3.sane-project.org/contrib.html and keep bug reports for 
> effective work.

I agree and therefore I wrote

        »… why I consider downstream reports good *in addition* to
        upstream reports.«

above.


Thanks,

Paul
-------------- 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/fde7d49d/attachment.pgp>