I wrote the following as my "first impressions" whinge after actually
following through a report with apport [for an issue I wasn't "invested"
enough in to report manually], after starting the process and giving up
many times prior.
I'd hate to just discard the wall of text I've built, but the conclusion
is in line with TerryG above... with some other items that should be
split out as separate bugs but have probably been reported already.
[I'm actually quite impressed how many issues have already been
acknowledged and marked as triaged or WIP..]
Treating 'automated reports' as a separate type of object seems like the
way to go. They're uninterpreted telemetry, the form is standardized,
and aside from cutting down "Bug" noise and misreporting by not
demanding they become "Bugs," they'd also be a lot easier to conduct
standardized data-mining/graphing/reporting on if they weren't mixed in
with our messy human-generated "Bug" objects (and the 'classification
noise,' as people decide which components to blame) too. Let humans
link the telemetry to "bugs" as they identify the real issue(s) the
telemetry is representing, not before they know what's going on.
...and as sugar, let the lazy-reporters only receive notification [if
they want] when their reports 'join' a bug object and when that bug is
resolved, without the noise in-between - they'll have the link in the
first notice if they want to check up on things. :)
So... all below are my initial observations, if they're any confirmation
or inspiration:
------
I think this is my first time using (or more specifically, following
through) with apport, and I can't avoid a gripe - hopefully
"constructive." I've previously considered using it, or specifically
followed half the steps of using it, but it's still less fun than a trip
to the DMV. Why?:
* apport makes no promises. It's not making any statement about what it avoids
collecting for privacy/security, so any user with half a clue is going to have
to stop and read closely.
- Note that apport is potentially *more* dangerous than trusting Microsoft,
since the apport data is going to be visible to the entire planet as soon as it
hits Launchpad, not just some corporate campus.
* apport does show the raw data. This is 'completely honest', but:
- Obvious: Who wants a drink from the firehose?
- Inobvious: Use of the expanding list widget causes some misbehaviors
/ surprising behaviors when it comes to scrolling; it is also extremely
easy to lose sight of which variable you're in once it scrolls out of
view.
- Inobvious?: A user can be quite familiar with UNIX and still be completely
unfamiliar with the xxx.xxx.xxx naming conventions in the report list. (Are
those GConf-isms, Linux /proc-isms, or specific to apport itself?)
A legend would be handy here, even if just in some [Help]. Knowing it's just
dmesg, `lspci`, `lsusb`, specific logfiles, etc. would make the vetting process
re: "Am I about to boneheadedly disclose something I shouldn't?" go much faster.
- Obvious: It's all-or-nothing; if you go through the trouble of
reading it all and *do* see something you'd rather obfuscate... time to
give up and start all over manually. In lieu of any special code,
having a box to uncheck per item (line-item veto) would be nice.
(Exists, #107103, triaged - cool.)
* Reporting through apport is "fire and... don't forget." When you're done
reviewing, it uploads your report - no surprise there. But then it dumps you
into Launchpad - Surprise, now you "have to" fill out a regular bug report
anyway -- or shrug it off and walk away. The issues here:
- Where did that upload go? Were those minutes spent reviewing the
generated report worthless unless I follow through writing up a regular
bug? [Maybe I'm an outlier, but I'm most likely to send an automated
report when something breaks but is *not* of personal
importance/interest/necessity. With nod to Douglas Adams, automated
reports are to let Someone Else know about Someone Else's Problems - if
an issue is troublesome enough for a user to really care about obtaining
a fix, it's *their* problem and they'll be personally invested enough to
open a regular bug. Including learning how to open a regular bug.]
- At present, Launchpad is taking the report and:
a) Leaving it up to the user to decide if their automated report - let's say
it was generated re: version 4096 of a package in the year 3208 - belongs in a
similar bug filed against version 0.001alpha in the year 13 B.C. This probably
isn't helping re: both of "misplaced me-toos" and "bad reviews" - when obsolete
instructions ("just go ahead and unpack 0.002.tar.gz into /, that'll fix it!")
naturally make things worse and harder to untangle.
b) Presenting a list of instructions at the bottom of the form I'm
typing into re: how to collect the information apport already collected.
Using apport (or `ubuntu-bug`, I guess). This gets circular.
c) Assigning this bug to 'linux' ... when someone will, eventually,
have to scrape through the attachments to relate it to the one specific
version it lies in. (Linux anterior 2.6.31-10-generic #32-Ubuntu SMP
Thu Sep 10 23:29:56 UTC 2009 x86_64 GNU/Linux, thanks for reading!)
Suggestions:
+ In lieu of major rework, give apport enough built-in help to document
where it's going to scrape from, what those scrapings are likely to
contain (the "apport variable" to "*NIX" name mapping issue), and where
it's sending the information.
+ If the user pushed send, they wanted to send the report. If redirected to
Launchpad, Launchpad shouldn't be demanding more work - it should be saying
"Thanks! I've received your report and I'm storing it with all the others."
Then an "If you want to open a bug for this item, click here." will be
perceived 'helpful,' not 'fill-this-out-in-triplicate.'
+ Automated reports are for data mining and quick notification
('something broke, you might never have known, here's telemetry') -
"like a mystery girl on the bus," and whoever has [or feels like taking]
responsibility can choose whether to get on or not. (If it's known to
be harmless - or fixed in version N+1 and can't be fixed in version N -
there's nothing to address unless an actual human voices a concern.)
"Bug reports," as in Bugzillas and Launchpads and the like, should be
written by humans to denote, track, and solve specific issues that
*humans* have identified in software. Because software never 'fails' -
it always runs as written, but doesn't always do what we want! If
someone notices an interesting trend in the automated reports - say,
because they're a subscribed maintainer - they can open a bug, detail
the issue as a human, and work to solve it.
I think the apport/Launchpad could be much more successful if it
maintains this separation - it'd cut down on 'well, I'm reporting it
because apport popped up' bugs like this one, take load off the
triageurs, yet also encourage more automated click-and-it's-done
reporting so real trends would be noted [hours? days? weeks?] sooner.
Look at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-
ati/+bug/419126/comments/39 for an example: right nobody [who isn't
tightly coupled to a problem] wants to report bugs during alpha phases,
because it's an alpha phase, "at your own risk," "not supposed to be
stable." But the more instrumentation you have that whups,-we-just-
took-out-everyone-with-chipset-X, the better the chance of fixing that
before release...
[Of course, this also means some sort of heartbeat might be good;
unintrusive might be associating anonymous hardware profiles with
cookies for http://start.ubuntu.com/ and looking for the sharp
statistical nosedive when every Brand_X system drops off the face of the
net.]
--
Automatic bug reporting not so automatic
https://bugs.launchpad.net/bugs/196172
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
