Hi, Interesting work. General question: is it planned to make "ls" an alias for the "list" subcommands (for instancen, in the attribute command)? 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"
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"?
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.
my
┌───┬──────────────┬──────┬──────┬───────────┬────┐ │cmd│ subcmd │prj wc│pkg wc│params/opts│note│ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │requests │ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │submitrequests│ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤
Do we really need to have the submitrequests subcommand?
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.
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".
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 :-)
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.
vc
vc should be an alias for a more explicit name: it means nothing to newcomers.
mkpac
┌─────┬──────┬──────┬──────┬────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│params/opts │note│ ├─────┼──────┼──────┼──────┼────────────┼────┤ │mkpac│ │x │ │package_name│ │ └─────┴──────┴──────┴──────┴────────────┴────┘
Merge with init?
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). Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org