On Fri, 22 Jul 2011 01:42:56 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
it has become quite obvious that there are different views about how much output flashrom should provide at default verbosity. I'd like to keep line count down, but at the same time I acknowledge that long-running operations need some user feedback. Those goals are not easily reconcilable and there will be some friction. Others would like to upgrade the message levels of quite a few messages and introduce a separate quiet mode which is less verbose than default mode.
Given that this dicussion revolves around the UI and different people expect different things, I don't want to "solve" this by decree. Instead, I hope for consensus.
i think you have read enough already from me regarding this :) so i try to not bore you even more in this message, but ill state a few generic rules for what i think is good default/minimum verbosity (also in the hope we get some company in this discussion, who should be aware of my stance).
the user should be informed about the main steps the program takes.
the user should be informed about any step that potentially takes longer than a few hundred milliseconds (upper bound for this minimum is about 2 seconds. anything longer should be announced in any case).
in the latter case there should be a starting message that explains what will happen with an appended ellipses and a finishing message that makes clear that the waiting time is over.
the user should be informed about any (permanent and transient) errors and its (potential) consequences (this includes "untested stuff" messages). depending on the complexity of the error, enough info to report the cause to the developers should be printed too (i dont mean mail addresses etc, but debugging content like which erase function has failed vs. "an" erase function has failed or pci ids). consequences are of course a hard topic with respect to verbosity, so this needs discussion and trade-offs in each case.
in probing there should be output about programmer(s)/board + chipset (and enables) and chips detected in a level the typical user understands. in other operating modes this is not really necessary (but in case of errors like chip not found).
We definitely need to reach a decision, but maybe we can do this with the help of use cases and by examining typical flashrom output.
i think we need to reach some decisions about some rules similar to the ones above. there is of course place for interpretation, but it would be very useful to have a common bag of rules that we think should be obeyed in general. each output can then be argued based on this rules which i think is easier and quicker than finding those rules by arguing all outputs independently :) they should also be written up on the developer guidelines page when we are done.
I'm sure
there is some low-hanging fruit where the message content/level can be adjusted and where people agree on the changes.
based on "my" rules above i can spot a few things like the header for example. no normal user needs to know the version or building environment at every program run. the "foss" banner could also be dropped". there is another line break in print_banner. so this would free 3 lines on all systems out there. instead of printing it every time there could be a --version parameter which would print those (alone). in more verbose modes the current behavior could be maintained.
that's just one example. if you disagree here.. np, let's focus on getting the rules "right" first.
sorry it got longer than i have hoped (again :)