On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering
Post by Lennart PoetteringI mean, just think of this: you have a pool of workstations to
administer. It's all the same machines, with the same prepared OS
image. You want to know about the backtraces as admin. Now, since the OS
images are all the same some errors will happen across all the machines
at the same time. Now, with your logic this would either result in all
of them downloading a couple of GB of debuginfo for glibc and stuff like
that, or all of them bombarding the retrace server, if they can.
No, someone administering a pool of machines would also want to
collect the crash information centrally instead of running tools
manually on every machine in the pool - and it turns out ABRT was from
the start designed to support such data collection; all core files can
be configured to end up at a single analysis machine.
The analysis machine can either have debuginfo installed locally (if
the single OS image is always the same) and just run gdb with full
information, or there can be a company-wide retrace server - it's an
open source project as well. At no moment is a system administrator
of a large pool of machines forced to send data to Fedora
infrastructure if they don't want to.
Post by Lennart PoetteringBut anyway, I don't think it's worth continuing this discussion, this is
a bit like a dialogue between two wet towels...
Let me try it one more time anyway, it seems to me that various use
cases were being mixed together in the reply quoting. There are about
three major different classes of users, depending on who is the "first
responder" to a particular crash (not depending no who will ultimately
want to review the information):
1) Developers of the software in question
2) Non-programming end-users.
3) System administrators who do not routinely deal with this
particular program, but may need to get as much data as possible.
and the discussion was mixing 1 and 2, and 2 and 3 fairly often.
My take:
1) Developers of the software in question: Bluntly, the ~1-100 users
in the whole world shouldn't matter in our discussion - if they are
even running the RPM, they can and probably will install complete
debuginfo, enable logging and do other non-default things to make
their job easier; The Fedora defaults don't matter that much for them,
and the mini debuginfo is not that useful either.
2) Non-programming end-users. _This_ is the case that we need to get
right by default. In many cases, a developer is lucky if the end
user ever sends any crash report, they often don't respond to
follow-up questions, and the problem does not have to be reproducible
at all. From such users we definitely want as full crash information
as possible (IOW, including the variable contents information) because
there won't be a second change to get it. The mini debuginfo is
therefore irrelevant, we need to steer users to the retrace server (or
to attaching full core files to reports, which has much worse privacy
impact).
3) System administrators who do not routinely deal with this
particular program, but may need to get as much data as possible.
Now, this is _not_ the case that we need to get right by default -
although it would be nice if we could. And the question is what will
the system administrators do with the information?
3a) The system administrator will try to fully debug the crash,
perhaps even preparing a patch. In that case they need full source
code, understand the program etc, and having to install full debuginfo
is really not too much to ask; mini debuginfo would be marginally
useful.
3b) The system administrator will only attempt to roughly understand
the problem (_this_ is what a typical kernel user does, e.g. "ah, SCSI
error handling is in the backtrace, so there must be something wrong
with the disk subsystem"). This is where mini debuginfo comes in
useful.
Can we agree on the above, at least that 1) and 2) are not noticeably
improved by mini debuginfo, and that 3b benefits from mini debuginfo?
(There may be disagreement about 3a, but I'm not inclined to worry
about it too much - it's fairly similar to 1) anyway).
If so, good - let's talk about whether we want the additional code
complexity and packaging complexity and space usage, to benefit 3b)
only. (I'd say that it's not something I would work on, and not
something FESCo should mandate that it must be supported, but if
someone else writes the code and either upstreams or the respective
Fedora package owners want to accept it, why not?).
BTW, the feature suggests mini debuginfo would be useful for userspace
tracing - AFAIK such uses, e.g. systemtap, use the variable location
information very extensively, and would thus not benefit from mini
debuginfo.
Mirek