Fwd: Default user feedback

[roger peppe]

[sending to the list proper this time!]

On 2 April 2013 10:15, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'd like to open up a discussion about how much user-feedback to give
> while running the "juju" client, and how we go about providing that
> feedback internally.
>
> Right now, juju commands are generally silent by default (no output
> unless --debug or --verbose[1] is supplied, unless there is a one line
> error report).

Yes, I think that silent-means-ok is a good default, with
considerable historical precedent. If there is to be any
output by default, I think it should be well formed and
contain useful information, not just expected messages.

> As part of sync-tools, I was making the tool a bit more user-focused,
> rather than script focused. So I generally output a message to the
> user for any operation that took more than a second or so.
>
> It was noted in review that this was different from all other commands
> to date.
>
> I believe Roger feels strongly that juju as a program should be
> designed for scripting first and user interaction second. (So the
> default should be silent, and the docs can just add "-v" to all the
> examples for users.)
>
> At which point, all messages go through the logging infrastructure,
> and we just tweak the default log level so that we get an
> "appropriate" level of communication at the "-v" level.
>
> I personally would prefer a user-focus first, with a flag to disable
> messages for scripting. But I certainly concede that it is best to be
> consistent, so that scripting and interactive users can know what to
> expect.
>
> I did try to do both:
>   lp:~jameinel/juju-core/sync-tools
>   lp:~jameinel/juju-core/sync-tools-logging
>
> You should be able to try them out by configuring an environment, and
> sourcing your EC2 credentials (into the bash ENV settings):
>
> $ cd cmd/juju
> $ go build
> $ ./juju sync-tools -e [target-env] [-v]
>
> I'm trying not to be too biased, so I'd appreciate it if people try it
> out. Here is a paste of both running:
> http://paste.ubuntu.com/5669878/

Here's my suggestion for how different flags might
affect the output of this command:

http://paste.ubuntu.com/5670147/

> I do feel there is a fundamental difference in the messages you should
> put to stdout/stderr during a command running, vs what you want to put
> into a log file. Though the juju client doesn't write to a log file
> without --log-path, so we could bias the client logging to be for
> user-visible messages.

I tend to agree here, although I can think of arguments both ways.

> [1] As a side note, --debug and --verbose are IMO undiscoverable. The
> only trail I found to them was:
>  juju help
>  juju help topics
>  juju help global-options
>
> There wasn't a breadcrumb from "juju help <command>" that global
> options even existed. If we do go with quiet-by-default, we probably
> need a better way of discovering '-v'.

I agree. I'd prefer it if each command printed all flags available on the
command, but perhaps I know Tim doesn't agree. At least some
indication that more flags are to be found elsewhere would be good.

  cheers,
    rog.