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>
