Mailinglist Archive: opensuse-buildservice (200 mails)

< Previous Next >
Re: [opensuse-buildservice] new osc user interface proposal
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >