On Tue, 16 Mar 2010, Michael Tokarev <m...@tls.msk.ru> wrote: > > Or kvm could use syslog or some other mechanism for logging such things. > > Where the error message will not be noticed either. With current > form it at least has a chance to be noticed after the guest exits.
There is no requirement that an error be logged in only one way. It's a fairly common practice to use both stderr and syslog for logging the same message. > In short, I disagree with your points, and think - based on my own > experience - that currently kvm does the best (modulo the error message > _text_). I fully agree about the usefulness of the particular error > message, and I already sent a patch to upstream fixing this (trivial > one-liner). Thanks. > For kvm we're talking about optional features, and how to react to them > lacking - either continue with a warning or stop - depends on the point > of view. A point of view which can be expressed by command-line options - similar to -Werror. > Ditto about error reporting in case of -curses. Note that the same > theme pops up in context of -daemon option, where kvm may actually > close stderr as you mentioned above. open /dev/kvm: Permission denied Could not initialize KVM, will disable KVM support Good point, when both /dev/kvm and /hugepages are unavailable with the -daemonize option only the above error is logged. > I'm relatively new to Debian still (speaking of package maintenance > anyway) and don't know how a maintainer usually should treat ideas > and suggestions about a package when said ideas are clearly should > be at least discussed with upstream, -- the actual author(s) of the > piece of software in question. There is some disagreement on this topic. I believe that a DD should forward requests to upstream. I believe that there are two situations where the DD should direct the reporter to contact upstream: 1) The DD refuses to support a feature without upstream support and upstream has indicated that they won't support it. 2) The DD thinks it's just a bad idea and uses "please contact upstream" to mean "please go away". With my packages I sometimes refer bugs upstream, and more often I fix the bugs and send the patch upstream. For me being a package maintainer is strongly correlated with being an upstream developer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
