Fwd: Default user feedback

[David Cheney]

Can this wait two weeks ? Ie, can we live with the differences between 
the new, helpful sync-tools and the older, gruffer, juju cli, til after 
13.04 ?

On 03/04/13 00:02, roger peppe wrote:
> [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.
>