[RFC] Several levels of expertise for bzr

[Matthieu Moy]

"Michael Ellerman" <michael at ellerman.id.au> writes:

> In short, no. Having options or commands that appear or disappear
> based on a magic[1] setting is only going to lead to more confusion.

I'm not talking about actually removing the commands. Just not mention
them in the help. Same for fancy options.

> Think of a user who happens to learn bzr on an "expert" install, on
> a shared machine, and then installs bzr on their own machine, only
> to find lots of commands missing.

We already have this problem. Someone who learns "shove", "rspush" or
so on a machine with bzrtools installed will find some missing
commands.

What I propose is just to replace

"Install bzrtools if you want to use this"

by

"Use them if you know them, and set the option to expert if you want
help to advertise for them"

> I think having levels of help is ok, but it should just be "bzr help",
> "bzr help commands" and (perhaps) "bzr help -v commands" etc.

That's another option. But then, I'd like to see it also for 
"bzr <command> --help": In general, we try to keep the number of
options low, but 

> [1] It's not magic to you and me, but it would be to a new user.

That's especially the point. Whether it's done by bzrtools Vs bzr core
separation or by a configuration option, the idea is that the new user
will _not_ have to set it.

Another drawback of the plugin approach is that it is usually
machine-wide. That means /my/ "bzr help commands" will change the day
/my sysadmin/ does a "aptitude install bzrtools". That's why I propose
a user option, not a system-wide install.

(that said, the separation plugin/core is still important to separate
supported commands from others, and to test some code before it's
included in the core)

-- 
Matthieu