On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Mon, 07.05.12 23:02, Jan Kratochvil (jan.kratochvil@xxxxxxxxxx) wrote: >> On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote: > I 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. > But 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
