On 2011-05-24 11:26:06 +0200, Vincent Untz wrote:
General question: is it planned to make "ls" an alias for the "list" subcommands (for instancen, in the attribute command)?
Yes I think we should also support aliases otherwise it isn't really "comfortable" (IMHO).
Some more specific comments below:
Le lundi 23 mai 2011, à 18:12 +0200, Marcus Hüwe a écrit :
meta
┌────┬──────┬──────┬──────┬──────────────────────┬────────────────────────┐ │cmd │subcmd│prj wc│pkg wc│ params/opts │ note │ ├────┼──────┼──────┼──────┼──────────────────────┼────────────────────────┤ │meta│ │x │ │ │shows/edits project meta│ ├────┼──────┼──────┼──────┼──────────────────────┼────────────────────────┤ │meta│ │ │x │ │shows/edits package meta│ ├────┼──────┼──────┼──────┼──────────────────────┼────────────────────────┤ │meta│ │ │ │api://project │ │ ├────┼──────┼──────┼──────┼──────────────────────┼────────────────────────┤ │meta│ │ │ │api://project/package │ │ ├────┼──────┼──────┼──────┼──────────────────────┼────────────────────────┤ │meta│ │ │ │api://project/_prjconf│ │ └────┴──────┴──────┴──────┴──────────────────────┴────────────────────────┘
I'm not a big fan of api://project/_prjconf as it kind of leaks an implementation detail (leading _) and can be confused with something related to a package. I think it'd make more sense to do "osc meta --prjconf api://project"
See below (person command).
attribute
┌─────────┬──────┬───┬───┬───────────────────┬────────────────────────────────┐ │ cmd │subcmd│prj│pkg│ params/opts │ note │ │ │ │wc │wc │ │ │ ├─────────┴──────┴───┴───┴───────────────────┴────────────────────────────────┤ │attribute is not context sensitive │ ├─────────┬──────┬───┬───┬───────────────────┬────────────────────────────────┤ │attribute│list │ │ │api://project │show all attributes │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│list │ │ │api://project │show specific attribute │ │ │ │ │ │attribute │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤
I'm not convinced "list" is the most intuitive term to show a specific attribute. Why not "show"/"cat"?
That can be changed easily.
request [...] submitrequest
If we keep submitrequest as a shortcut to "request create --submit", then both should behave exactly the same way. The fact that "request create --submit" ignores the wc creates an unneeded difference, imho.
I'm not exactly sure why "request create" ignores the current context in general, btw. Since the request will have to be accepted, accidentally causing some bad thing sounds unlikely.
Yes we can make it context sensitive too. I just thought about it again and it shouldn't cause any bigger problems (also with regard to the implementation).
my
┌───┬──────────────┬──────┬──────┬───────────┬────┐ │cmd│ subcmd │prj wc│pkg wc│params/opts│note│ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │requests │ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │submitrequests│ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤
Do we really need to have the submitrequests subcommand?
It was just added for backward compatibility but you're right it's probably the best to drop it, too.
importsrcpkg
┌────────────┬──────┬──────┬──────┬─────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────────────┼──────┼──────┼──────┼─────────────┼────┤ │importsrcpkg│ │x │ │/path/to/srpm│ │ └────────────┴──────┴──────┴──────┴─────────────┴────┘
This command is badly named. I'd merge it with init.
That sounds like a good idea... it belongs to mkpac or init.
person For groups we can add a new "group" command
┌──────┬──────────┬────┬────┬───────────────────────┬─────────────────────────┐ │ cmd │ subcmd │prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────┼──────────┼────┼────┼───────────────────────┼─────────────────────────┤ │person│meta │ │ │api://username <--edit>│ │ ├──────┼──────────┼────┼────┼───────────────────────┼─────────────────────────┤ │person│maintainer│ │ │api://project/<package>│show maintainer of the │ │ │ │ │ │ │project/package │ ├──────┼──────────┼────┼────┼───────────────────────┼─────────────────────────┤ │person│maintainer│ │ │api://project/<package>│show maintainer of the │ │ │ │ │ │ │project/package │ ├──────┼──────────┼────┼────┼───────────────────────┼─────────────────────────┤ │person│add │ │ │api://project/<package>│ │ │ │ │ │ │user role │ │ ├──────┼──────────┼────┼────┼───────────────────────┼─────────────────────────┤ │person│delete │ │ │api://project/<package>│ │ │ │ │ │ │user <role> │ │ └──────┴──────────┴────┴────┴───────────────────────┴─────────────────────────┘
I'm nearly sure that "person add/delete" is not intuitive enough to discover. The way people will think about it is: "I want to edit the roles in the metadata, so it's something like 'osc meta'", and they'll end up doing "osc meta --edit".
"osc person" sounds more like "I want to do an action on the person", not "on the metadata".
Hmm yes that might confuse users. We could use the "osc meta --user" pattern here (as you already suggested with "osc meta --prjconf") to edit the user meta (instead of "osc person meta"). I really want to avoid that we end up with something like "meta --user username --add maintainer api://project" because if we do it like this the "meta" command will "explode" (again).
cat
┌───┬──────┬──────┬──────┬──────────────────────────┬────┐ │cmd│subcmd│prj wc│pkg wc│ params/opts │note│ ├───┼──────┼──────┼──────┼──────────────────────────┼────┤ │cat│ │ │ │api://project/package/file│ │ └───┴──────┴──────┴──────┴──────────────────────────┴────┘
I'd love if cat would also work on api://project/package and just behave as ls in that case. Happens to me all the time :-)
Hmm could be possible but it might be a bit "counterintuitive" (when I read the first part of your sentence, I thought it should print the raw meta data).
repair
┌──────┬──────┬─────┬─────┬──────────────────────────────────────────────┬────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │note│ │ │ │ wc │ wc │ │ │ ├──────┼──────┼─────┼─────┼──────────────────────────────────────────────┼────┤ │repair│link │ │x │ │ │ ├──────┼──────┼─────┼─────┼──────────────────────────────────────────────┼────┤ │repair│link │ │ │api://project/package <api://into_project/ │ │ │ │ │ │ │<into_package>> │ │ ├──────┼──────┼─────┼─────┼──────────────────────────────────────────────┼────┤ │repair│wc │x │ │ │ │ ├──────┼──────┼─────┼─────┼──────────────────────────────────────────────┼────┤ │repair│wc │ │x │ │ │ └──────┴──────┴─────┴─────┴──────────────────────────────────────────────┴────┘
"wc" doesn't make sense to most users. Something more explicit should be used.
Right.
vc
vc should be an alias for a more explicit name: it means nothing to newcomers.
As long as we keep the "vc" alias I'm fine with it.
mkpac
┌─────┬──────┬──────┬──────┬────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│params/opts │note│ ├─────┼──────┼──────┼──────┼────────────┼────┤ │mkpac│ │x │ │package_name│ │ └─────┴──────┴──────┴──────┴────────────┴────┘
Merge with init?
Hmm I'll think about it but you're right.. init is probably a good place for it.
setlinkrev linktobranch detachbranch
Those three sound like "old" names. There's probably something that could be done to either rename them, or move them to subcommands (of link or branch, for instance).
Exactly - that's something which doesn't really fit into any of the existing groups... Thanks _a lot_ for your detailed feedback! Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org