I thought I'd split this thread into two. One question is about what benefits error reporting on Server might bring, and that's what I'd like to discuss here.
> [Daviey] Just need to work out, *if* it is worth doing... Is it worth doing? What sorts of errors will we pick up on right now? Do these errors happen in the real world? With us diverting effort to this, are we going to neglect some category of errors that we currently won't pick up this way? Some categories of errors come to mind: 1) Segfaults leading to core dumps. I don't see many bug reports of these at all. We do get the occasional excellent bug report though. My feeling is that segfaults on server are actually quite rare. 2) Maintainer script failures. We get lots of these reports. Most of them are due to local misconfiguration or sysadmin error in a way that I don't think it's possible or reasonable for us to fix. This is because most use cases of server packages involve sysadmin configuration file editing. Perhaps this can be fixed at a higher layer (eg. charms being careful to not introduce these kinds of errors). I think these reports aren't useful individually for this reason, but may be useful in aggregate to identify real bugs. So it seems to me that error reporting for these would be really useful. 3) Perhaps daemon start failures that aren't from maintainer script failures? This is subject to the same sysadmin misconfiguration problem above though; I'm not sure how useful this would be. What other kinds of errors will we initially pick up on? What categories have I missed, or does anyone disagree with my analysis above? Is it worth doing this just to be able to analyse maintainer script failures? Robie -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
