[flashrom] Message levels and content

[Stefan Tauner]

On Fri, 22 Jul 2011 01:42:56 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at 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 :)
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner