[sane-devel] [RFC] Why I consider downstream bug reports a good thing
paulepanter at users.sourceforge.net
Mon Feb 18 17:08:17 UTC 2013
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” .
> > 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  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
> >  – 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
> >  http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/030914.html
> >  https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bugs
> >  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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the sane-devel