Fwd: Default user feedback

[William Reade]

On Wed, 2013-04-03 at 00:16 +1100, David Cheney wrote:
> 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 ?

Assuming we land John's branch as soon as possible, I'm happy for us to
discuss logging, and user output, and how and where they might
intersect, over email; but I would be sad if anyone were devoting a
significant proportion of their workday to such a discussion.

Most importantly, I'd like to have a proper conversation about this
live, in Oakland, incorporating gustavo's feedback from the other
thread; and get it prioritised alongside our other goals. For now, we
should not spend any more coding time on the problem.

Cheers
William

> 
> 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.
> >
>