Simple Scan triaging

[Brian Murray]

On Wed, Nov 30, 2011 at 12:15:29AM +0100, Michael Nagel wrote:
> Hi there,
> 
> I am writing to this list because I would like to hear your opinion
> regarding the following problem:

Thanks for bringing this up.
 
> I am triaging the bugs filed against the simple-scan package and the
> Simple Scan project itself. There are a lot of bug reports like [1]
> (randomly picked that one) where the hardware is not supported
> properly. Either it is not supported at all, or some features (ADF,
> ...) are missing. These bug reports do not bring forward the
> development of Simple Scan, but on the contrary clog the bug lists and
> slow down development progress. Keeping them is thus not worthwile in
> my opinion. (Note: In general I think not all bug reports should be
> accepted/kept. I prefer a deliberate decision with explicit
> downsides/compromises to the implicit decision to do nothing and avoid
> all downsides -- you do not get upsides that way, either.)

With apport we have a great tool on the desktop for receiving higher
quality bug reports and dealing with issues like this before they become
bug reports in Launchpad.  For an example of what I'm talking about
try executing 'ubuntu-bug storage'.  Following this process the reporter
is asked to perform different activities to help determine what package
the issue is with.   Something similar could be done with apport package
hook for simplescan.  Additionally, if the issue were one with hardware
being unsupported reporting of the bug could be prevented or it could be
filed about a different package.  I've given a couple of classes on
writing apport package hooks and I'm happy to help with this or answer
any questions.

> Different stakeholders are involved in these bug, namely the original
> reporter, the Simple Scan developers, the developers of SANE / other
> involved software, and other users owning the same hardware. Keeping
> these reports open helps none of them and harms some of them. The
> following approach would be much better for everyone in my opinion:
> 
> 1) closing such bugs in a timely manner 2) pointing to a wiki where
> general tips about scanners can be much better maintained. might be an
> adapted version of [2] 3) structured information about what hardware
> works with what settings should be kept in a database (in the weak
> meaning of the word, might e.g. be another wiki page). might just be
> [3]

I think having a wiki page regarding scanners and tips make sense and
you could even put this information in the package hook for simplescan.

> - The original reporter benefits from 1) because he no longer is
> ignored for some years. The reporter hopefully benefits from 2+3) as
> there is the chance (s)he gets the scanner to work.  - The Simple Scan
> developers benefit from happy users and from more helpful bug lists,
> letting them concentrate on the real issues in Simple Scan.  - SANE /
> other developers benefit from 3) because they get much more concise
> and structured information. See the following section about forwarding
> bugs.  - Other hardware owners profit from the database as well,
> because they can easily find out what hardware can be recommended to
> buy (use case 1) and what can be expected from a given piece of
> hardware (use case 2a) and how to get the most out of a given piece of
> hardware (use case 2b).
> 
> About forwarding such bug reports to e.g. sane-backends: I think it is
> monkey business, like some European countries moving around atomic
> waste that nobody wants but that does not vanish. It would just create
> the same situation we have with simple-scan now for sane-backends in
> some time. Someone has to accept responsibility, make the though
> decision (see above) and "solve" the issue.
> 
> Additionally, these bugs are often reported by new users, very vague
> and to not include enough technical detail. I am sure there has been
> some discussion how to handle that kind of bug reports, as Ubuntu
> continues to attract more and more non-technical users that cannot
> and/or do not want to contribute low-level.  A pointer to such
> discussion would be very welcome!  From my experience those users are
> mostly thankful for some timely, helpful and honest reply, even if it
> boils down to "yes, we know, but sadly it will not be fixed soon -- if
> you need a solution right now and you cannot code: I am sorry to tell
> you, but your only option is to buy one of the better supported
> scanners. More info: see wiki: ..." Once again: if the bug report is
> just another data point saying "does not work" it is better off in the
> device database.
> 
> Then, even trickier, are the crashes of Simple Scan (or more likely:
> SANE/something down the chain) that depend on the use of certain
> hardware (with bad drivers). To be honest, nobody will look into these
> issues because of a bug report. Either someone knowledgeable will look
> into such an issue because he is personally affected or because
> someone (s)he knows is affected.  But the mere statement that Simple
> Scan crashed (typically via an apport report) will once again lead to
> rotting/stale bug reports, where developers benefit from just deleting
> it and non-technical users benefit most from a timely pointer to the
> wiki and the database where they can get a tip how to maybe get it
> working. One prominent tip should read: "If you need a solution right
> now and you cannot code: I am sorry to tell you, but your only option
> is to buy one of the better supported scanners. More info: see wiki:
> ..."

Is it possible to programmatically determine from the crash report
whether or not it was a driver issue or not?  If so these can also be
prevented from being reported in the package hook for simple scan.
However, how would you distinguish between the "bad" drivers and the
"good" drivers?

--
Brian Murray
Ubuntu Bug Master
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20111201/3733d8da/attachment.sig>