[opensuse-buildservice] new osc user interface proposal
Hi, as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws". Here are some examples to show some flaws of the current user interface: * inconsistent ui: - osc results project package --repo repo --arch arch - osc rebuild project package repo arch - osc build repo arch - osc ls project package repo arch -b - osc ls project package -r repo -a arch -b - osc undelete project package_1 ... package_N - osc rdelete project package_1 * counterintuitive commands: - osc abortbuild project package - osc abortbuild project package repo arch - osc abortbuild (in a package working copy) - osc abortbuild --repo repo --arch arch (in a package working copy) - osc abortbuild repo arch (in a package working copy) => treats "repo" "arch" as "project" "package" * "duplicated" commands: - diff, rdiff - buildlog, remotebuildlog, localbuildlog - delete, rdelete, rremove Additionally we support lots of commands and the output of "osc --help"is quite long. In order to tackle this problem we decided to introduce "groups" with subcommands, for instance: attribute list attribute create... attribute set... ... As a result we get rid of "god commands" (commands which supported lots of different options for different things (like osc meta)) and the new commands are easier to use because they support less arguments and/or options (note: this doesn't mean we lose functionality - the functionality is just moved to another command/command group). The attached files are just a _proposal_ for a new commandline user interface. Some additional explanations: The biggest change with regard to our current user interface is the introduction of an url-like syntax: For example: osc ls api://project/package instead of osc ls project package In this case "api" means that the request is issued to the default apiurl (in most cases https://api.opensuse.org) which can be configured in the ~/.oscrc. To issue the "list" request to a different obs instance one can use: osc ls https://api.somehost/project/package or osc ls alias://project/package "alias" is an alias for this apiurl which can be configured in the ~/.oscrc. If you see this url-like syntax for the first time you might think that it makes things much more complicated (and even more to type) but it is advantageous: - in most cases it is obvious if a command is a remote command or local working copy command - this way we get rid of ambiguities: Suppose we support the following command ("<foo>" indicate that "foo" is an optional argument): binaries get api://project/package <repo/arch> binaries get <repo/arch> (if $PWD is a package working copy the project and package arguments will be read from it) Possible invocations are: osc binaries get api://foo/bar standard/i586 # get all binaries for this repo and arch osc binaries get api://foo/bar # get all binaries for all repos and all arches # now suppose $PWD is a package working copy: osc binaries get standard/i586 # get all binaries for this repo and arch (project and package are read from the working copy) osc binaries get api://foo/bar # gets all binaries for all repos and all arches (project is "foo" and package is "bar") In the latter invocation we're still in a package working copy but ignore it and use the project and package arguments which were specified. Note: in this case a special (like the url-like) syntax is required otherwise osc is unable to distinguish between a project/package and repo/arch argument. Once again this is just a _proposal_ - feedback is very welcome! Marcus [1] http://www.google-melange.com/gsoc/project/google/gsoc2011/mhuewe/13001 The attached ui.html.gz file can be used to navigate easier through the list of commands (I just gzip'ed it to make mlmmj happy). The attached ui.txt file is just generated via "w3m -dump ui.html".
Am Monday, 23. May 2011, 18:12:51 schrieb Marcus Hüwe:
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws".
In short, great new proposal, I have not many remarks yet, but I will think about it :) Just one idea of mine, I would like to integrate requests more smoothly into osc and also webui. For me this means work as usual as long as possible and if it does not work due to lack of permissions, the client should ask for creating a request instead. For example osc delete $PROJECT deletes the project. If it can't be done, osc should ask the user to create a request instead. One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via osc delete --request $PROJECT This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that). As a consequence we would need to add commands for all request types in the api (which is not the case for "submit" for example. I see people with write permissions in the target creating requests just for convenience. However, not a good idea, because it sends out unwanted notifications). That "submit" command is something I want to do after 2.3 ASAP in any case. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Monday, 23. May 2011, 21:19:25 schrieb Adrian Schröter:
Am Monday, 23. May 2011, 18:12:51 schrieb Marcus Hüwe:
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws".
In short, great new proposal, I have not many remarks yet, but I will think about it :)
Just one idea of mine, I would like to integrate requests more smoothly into osc and also webui. For me this means work as usual as long as possible and if it does not work due to lack of permissions, the client should ask for creating a request instead. For example
osc delete $PROJECT
deletes the project. If it can't be done, osc should ask the user to create a request instead.
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :) Do you think it makes sense ?
As a consequence we would need to add commands for all request types in the api (which is not the case for "submit" for example. I see people with write permissions in the target creating requests just for convenience. However, not a good idea, because it sends out unwanted notifications).
That "submit" command is something I want to do after 2.3 ASAP in any case.
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Monday, 23. May 2011, 21:19:25 schrieb Adrian Schröter:
Am Monday, 23. May 2011, 18:12:51 schrieb Marcus Hüwe:
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws".
In short, great new proposal, I have not many remarks yet, but I will think about it :)
Just one idea of mine, I would like to integrate requests more smoothly into osc and also webui. For me this means work as usual as long as possible and if it does not work due to lack of permissions, the client should ask for creating a request instead. For example
osc delete $PROJECT
deletes the project. If it can't be done, osc should ask the user to create a request instead.
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :)
Do you think it makes sense ? I'd say 'osc delete' could create a request if you are not a maintainer of the target much like the webui currently does. One could argue though, that it may make sense to ask the other 10 maintainers before you delete a devel:foo
On Monday 23 May 2011 21:26:18 Adrian Schröter wrote: project. Instead of a request, osc could ask for confirmation if there are other maintainers or packages in the project. This would create some social presure to get in touch with the others. If you want to delete sth under your home: project, nobody cares. If you want to delete, say, Base:System, you should get in touch with your co-maintainers, not just ask them for confirmation.
As a consequence we would need to add commands for all request types in the api (which is not the case for "submit" for example. I see people with write permissions
in the target creating requests just for convenience. However, not a good idea, because it sends out unwanted notifications).
That "submit" command is something I want to do after 2.3 ASAP in any case.
-- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
Am Tuesday, 24. May 2011, 08:49:04 schrieb Sascha Peilicke:
Am Monday, 23. May 2011, 21:19:25 schrieb Adrian Schröter:
Am Monday, 23. May 2011, 18:12:51 schrieb Marcus Hüwe:
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws".
In short, great new proposal, I have not many remarks yet, but I will think about it :)
Just one idea of mine, I would like to integrate requests more smoothly into osc and also webui. For me this means work as usual as long as possible and if it does not work due to lack of permissions, the client should ask for creating a request instead. For example
osc delete $PROJECT
deletes the project. If it can't be done, osc should ask the user to create a request instead.
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :)
Do you think it makes sense ? I'd say 'osc delete' could create a request if you are not a maintainer of the target much like the webui currently does. One could argue though, that it may make sense to ask the other 10 maintainers before you delete a devel:foo
On Monday 23 May 2011 21:26:18 Adrian Schröter wrote: project. Instead of a request, osc could ask for confirmation if there are other maintainers or packages in the project. This would create some social presure to get in touch with the others. If you want to delete sth under your home: project, nobody cares. If you want to delete, say, Base:System, you should get in touch with your co-maintainers, not just ask them for confirmation.
Yes, you should get in touch. However, I do not see how an automatism can help here. We could add every single maintainer as reviewer of such a request, but from a realistic standpoint there will be always some not reacting maintainer and the request would be blocked. This discussion may lead to far away from the original osc UI proposal now, but if we agree that osc should ask for creating requests in 403 cases (if no --batch option got added) this would have an effect on the CLI UI. good morning adrian
As a consequence we would need to add commands for all request types in the api (which is not the case for "submit" for example. I see people with write permissions
in the target creating requests just for convenience. However, not a good idea, because it sends out unwanted notifications).
That "submit" command is something I want to do after 2.3 ASAP in any case.
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 24 May 2011 09:02:02 Adrian Schröter wrote:
Am Tuesday, 24. May 2011, 08:49:04 schrieb Sascha Peilicke:
On Monday 23 May 2011 21:26:18 Adrian Schröter wrote:
Am Monday, 23. May 2011, 21:19:25 schrieb Adrian Schröter:
Am Monday, 23. May 2011, 18:12:51 schrieb Marcus Hüwe:
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws".
In short, great new proposal, I have not many remarks yet, but I will think about it :)
Just one idea of mine, I would like to integrate requests more smoothly into osc and also webui. For me this means work as usual as long as possible and if it does not work due to lack of permissions, the client should ask for creating a request instead. For example
osc delete $PROJECT
deletes the project. If it can't be done, osc should ask the user to create a request instead.
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :)
Do you think it makes sense ?
I'd say 'osc delete' could create a request if you are not a maintainer of the target much like the webui currently does. One could argue though, that it may make sense to ask the other 10 maintainers before you delete a devel:foo project. Instead of a request, osc could ask for confirmation if there are other maintainers or packages in the project. This would create some social presure to get in touch with the others. If you want to delete sth under your home: project, nobody cares. If you want to delete, say, Base:System, you should get in touch with your co-maintainers, not just ask them for confirmation.
Yes, you should get in touch. However, I do not see how an automatism can help here. Isn't that what I just said? :-)
We could add every single maintainer as reviewer of such a request, but from a realistic standpoint there will be always some not reacting maintainer and the request would be blocked. Yep, I agree that reviews aren't the ideal solution here.
This discussion may lead to far away from the original osc UI proposal now, but if we agree that osc should ask for creating requests in 403 cases (if no --batch option got added) this would have an effect on the CLI UI. I think this would make sense, currently osc ditches by saying 'I can't do that with the command you issued, but add this parameter and I could". An example is 'osc build' vc 'osc build --local-package'. Instead, it should be clever and do the right thing right away, our just ask for confirmation if in doubt. This way we avoid cluttering the CLI once again.
@suse-tux: Isn't that sth. you hand in mind anyway?
good morning adrian
As a consequence we would need to add commands for all request types in the api (which is not the case for "submit" for example. I see people with write permissions
in the target creating requests just for convenience. However, not a good idea, because it sends out unwanted notifications).
That "submit" command is something I want to do after 2.3 ASAP in any case.
-- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
On May 23, 11 21:26:18 +0200, Adrian Schröter wrote:
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :) Do you think it makes sense ?
Without context, this command looks like it would remove a request. With the context you explained, I understand that it creates a request. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Immendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Tuesday, 24. May 2011, 13:58:40 schrieb Juergen Weigert:
On May 23, 11 21:26:18 +0200, Adrian Schröter wrote:
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :) Do you think it makes sense ?
Without context, this command looks like it would remove a request. With the context you explained, I understand that it creates a request.
Right, Just discussed with Sascha, what about osc delete $project [$package] Tries to delete and falls back to create a request. In the same way as osc request delete $project [$package] would work. osc --batch delete ... would not fallback. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Tuesday, 24. May 2011, 13:58:40 schrieb Juergen Weigert:
On May 23, 11 21:26:18 +0200, Adrian Schröter wrote:
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :) Do you think it makes sense ?
Without context, this command looks like it would remove a request. With the context you explained, I understand that it creates a request.
Right, Just discussed with Sascha, what about
osc delete $project [$package]
Tries to delete and falls back to create a request. IMHO osc should inform the user that he/she has insufficient
On 2011-05-24 15:18:33 +0200, Adrian Schröter wrote: permissions to delete the project or package and osc should ask if a deleterequest should be created.
In the same way as
osc request delete $project [$package]
would work.
osc --batch delete ...
would not fallback.
Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello, On May 24 16:17 Marcus Hüwe wrote (excerpt):
IMHO osc should inform the user that he/she has insufficient permissions to delete the project or package and osc should ask if a deleterequest should be created.
Yes, the new user interface should do a bidirectional communication with its user when something is missing or wrong, see my other mail. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
On May 24, 11 15:18:33 +0200, Adrian Schröter wrote:
Am Tuesday, 24. May 2011, 13:58:40 schrieb Juergen Weigert:
On May 23, 11 21:26:18 +0200, Adrian Schröter wrote:
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :) Do you think it makes sense ?
Without context, this command looks like it would remove a request. With the context you explained, I understand that it creates a request.
Right, Just discussed with Sascha, what about
osc delete $project [$package]
Tries to delete and falls back to create a request. In the same way as
osc request delete $project [$package]
would work.
osc --batch delete ...
would not fallback.
The word order 'delete --request', or 'request delete' does not make much difference, both appears ambiguous to me. An implicit fallback might not be what a user expects either. How about this: osc delete $project $package Always sends a delete request, printing out a message "Delete request #123456 created." In case the user has permission to delete the packge himself, it also prints out a message informing him. "You can use 'osc rq accept 123456' to delete $package now." osc delete --force $project $package Immediatly deletes, saying "Package $package deleted." if the user has the permissions. It behaves identical to sending and immediatly approving a delete request. Otherwise it fails and suggests "You can use 'osc delete $project $package' (without --force) to send a delete request." Note that I avoid the verb 'create' in the context of delete requests. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Immendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Tuesday, 24. May 2011, 18:40:44 schrieb Juergen Weigert:
On May 24, 11 15:18:33 +0200, Adrian Schröter wrote:
Am Tuesday, 24. May 2011, 13:58:40 schrieb Juergen Weigert:
On May 23, 11 21:26:18 +0200, Adrian Schröter wrote:
One may also offer a standard parameter to enforce the request creation (because you may want that others check this). This could be done via
osc delete --request $PROJECT
This may be a replacement for the "osc request create" command to some degree (multiple actions per request would not work with that).
please understand this also as a RFC proposal :) Do you think it makes sense ?
Without context, this command looks like it would remove a request. With the context you explained, I understand that it creates a request.
Right, Just discussed with Sascha, what about
osc delete $project [$package]
Tries to delete and falls back to create a request. In the same way as
osc request delete $project [$package]
would work.
osc --batch delete ...
would not fallback.
The word order 'delete --request', or 'request delete' does not make much difference, both appears ambiguous to me. An implicit fallback might not be what a user expects either.
How about this:
osc delete $project $package
Always sends a delete request, printing out a message "Delete request #123456 created."
Definitive not a good idea. Requests trigger notifications and we want to keep the unwanted noise as low as possible.
In case the user has permission to delete the packge himself, it also prints out a message informing him. "You can use 'osc rq accept 123456' to delete $package now."
osc delete --force $project $package
Immediatly deletes, saying "Package $package deleted." if the user has the permissions. It behaves identical to sending and immediatly approving a delete request.
Otherwise it fails and suggests "You can use 'osc delete $project $package' (without --force) to send a delete request."
Note that I avoid the verb 'create' in the context of delete requests.
cheers, JW-
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Le mardi 24 mai 2011, à 18:47 +0200, Adrian Schröter a écrit :
Am Tuesday, 24. May 2011, 18:40:44 schrieb Juergen Weigert:
How about this:
osc delete $project $package
Always sends a delete request, printing out a message "Delete request #123456 created."
Definitive not a good idea. Requests trigger notifications and we want to keep the unwanted noise as low as possible.
Are packages explicitly deleted that often? I don't expect that much noise from delete notifications. FWIW, the biggest issue I see with Jürgen's proposal is this: osc delete --force $project Does this force the deletion of a non-empty project or does it go to delete without a delete request? 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
Am Wednesday, 25. May 2011, 09:26:29 schrieb Vincent Untz:
Le mardi 24 mai 2011, à 18:47 +0200, Adrian Schröter a écrit :
Am Tuesday, 24. May 2011, 18:40:44 schrieb Juergen Weigert:
How about this:
osc delete $project $package
Always sends a delete request, printing out a message "Delete request #123456 created."
Definitive not a good idea. Requests trigger notifications and we want to keep the unwanted noise as low as possible.
Are packages explicitly deleted that often? I don't expect that much noise from delete notifications.
Well, yes, and to be consistent, it would also be used with the other commands like commit and so on ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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
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
Hello, On May 23 18:12 Marcus Hüwe wrote (excerpt):
The current user interface is quite "inconsistent"
I appreciate very much any new user interface which is consistent from the users's point of view. Feel free to change the current interface as needed. All what matters is consistency. A very general wish: The new user interface should do a bidirectional communication with its user whenever something is missing or wrong. Not the traditional two-times unidirectional way: First an unidirectional command sent by the user. Then an unidirectional (error)-message as response. Examples: Traditional way: ---------------------------------------------------------------- user@host$ osc cat openSUSE:11.4 grep Wrong number of arguments. user@host$ ---------------------------------------------------------------- Bidirectional communication way: ---------------------------------------------------------------- user@host$ osc cat openSUSE:11.4 grep api.opensuse.org: enter file name (? for help) api.opensuse.org: ---------------------------------------------------------------- Traditional way: ---------------------------------------------------------------- user@host$ osc cat openSUSE:1.4 grep grep.spec expanding link... Server returned an error: HTTP Error 404: Not Found openSUSE:1.4 user@host$ ---------------------------------------------------------------- Bidirectional communication way: ---------------------------------------------------------------- user@host$ osc cat openSUSE:1.4 grep grep.spec api.opensuse.org: project 'openSUSE:1.4' not found api.opensuse.org: enter project name (? for help) api.opensuse.org: ---------------------------------------------------------------- Note that bidirectional communication happens only when something is missing or wrong. When using complete right commands the new user interface should work in the traditional way so that it can also be used in scripts without artificial "--silent" parameters. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
On Mon, May 23, Marcus Hüwe wrote: Please keep in mind, that osc is an api to access obs. People might use osc to integrate with obs as I do. When you break the osc api at least for me that will result in a bigger mess. That might be valid for others, too. Instead of breaking the api of the existing osc, I'd suggest to create a new osc (e.g. osc2 or whatever) and keep the old one for a while.
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws". Here are some examples to show some flaws of the current user interface:
* inconsistent ui: - osc results project package --repo repo --arch arch - osc rebuild project package repo arch - osc build repo arch - osc ls project package repo arch -b - osc ls project package -r repo -a arch -b - osc undelete project package_1 ... package_N - osc rdelete project package_1
* counterintuitive commands: - osc abortbuild project package - osc abortbuild project package repo arch - osc abortbuild (in a package working copy) - osc abortbuild --repo repo --arch arch (in a package working copy) - osc abortbuild repo arch (in a package working copy) => treats "repo" "arch" as "project" "package"
* "duplicated" commands: - diff, rdiff - buildlog, remotebuildlog, localbuildlog - delete, rdelete, rremove
Additionally we support lots of commands and the output of "osc --help"is quite long. In order to tackle this problem we decided to introduce "groups" with subcommands, for instance: attribute list attribute create... attribute set... ...
As a result we get rid of "god commands" (commands which supported lots of different options for different things (like osc meta)) and the new commands are easier to use because they support less arguments and/or options (note: this doesn't mean we lose functionality - the functionality is just moved to another command/command group).
The attached files are just a _proposal_ for a new commandline user interface.
Some additional explanations:
The biggest change with regard to our current user interface is the introduction of an url-like syntax: For example: osc ls api://project/package instead of osc ls project package
In this case "api" means that the request is issued to the default apiurl (in most cases https://api.opensuse.org) which can be configured in the ~/.oscrc. To issue the "list" request to a different obs instance one can use: osc ls https://api.somehost/project/package or osc ls alias://project/package "alias" is an alias for this apiurl which can be configured in the ~/.oscrc.
If you see this url-like syntax for the first time you might think that it makes things much more complicated (and even more to type) but it is advantageous:
- in most cases it is obvious if a command is a remote command or local working copy command - this way we get rid of ambiguities: Suppose we support the following command ("<foo>" indicate that "foo" is an optional argument): binaries get api://project/package <repo/arch> binaries get <repo/arch> (if $PWD is a package working copy the project and package arguments will be read from it)
Possible invocations are: osc binaries get api://foo/bar standard/i586 # get all binaries for this repo and arch osc binaries get api://foo/bar # get all binaries for all repos and all arches
# now suppose $PWD is a package working copy: osc binaries get standard/i586 # get all binaries for this repo and arch (project and package are read from the working copy)
osc binaries get api://foo/bar # gets all binaries for all repos and all arches (project is "foo" and package is "bar")
In the latter invocation we're still in a package working copy but ignore it and use the project and package arguments which were specified.
Note: in this case a special (like the url-like) syntax is required otherwise osc is unable to distinguish between a project/package and repo/arch argument.
Once again this is just a _proposal_ - feedback is very welcome!
Marcus
[1] http://www.google-melange.com/gsoc/project/google/gsoc2011/mhuewe/13001
The attached ui.html.gz file can be used to navigate easier through the list of commands (I just gzip'ed it to make mlmmj happy). The attached ui.txt file is just generated via "w3m -dump ui.html".
init, list, meta, attribute, request, submitrequest, review, link, copy, maintenance, branch, delete, undelete, diff, checkout, status, add, addremove, commit, update, resolved, distributions, results, buildlog, buildmeta, build, chroot, log, service, abortbuild, rebuild, binaries, search, my, importsrcpkg, person, cat, less, repair, pull, signkey, vc, mv, config, revert, api, aggregate, mkpac, setlinkrev, linktobranch, detachbranch
setlinkrev, linktobranch and detachbranch might be grouped into group "other". Deleted commands:
┌──────────────────────┬──────────────┬───────────────────────────────────────┐ │ cmd │ replacement │ reason │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │deleterequest args │request create│ │ │ │--delete args │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │ │request create│ │ │reqeuestmaintainership│--role │ │ │args │maintainer │ │ │ │args │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │changedevelrequest │request create│ │ │args │--changedevel │ │ │ │args │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │request approvenew │ │request --interactive-review could be │ │project <package> │ │used (but it's no real replacement) │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │request log id │request show │ │ │ │id --log │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │linkpac │link │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │copypac │copy │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │releaserequest │maintenance │ │ │ │releaserequest│ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │createincident │maintenance │ │ │ │createincident│ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │maintenancerequest │maintenance │ │ │ │request │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │mbranch │maintenance │ │ │ │branch │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │getpac │ │use branch │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │rdelete │delete │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │updatepacmetafromspec │ │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │rdiff │diff │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │ │ │no replacement atm (current │ │linkdiff │ │implementation partly broken); diff │ │ │ │could support it │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │repourls │ │isn't needed IMHO │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │prjresults │results │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │remotebuildlog │buildlog │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │localbuildlog │buildlog │ │ │ │--local │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │buildinfo │buildmeta info│ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │buildconfig │buildmeta │ │ │ │config │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │triggerreason │buildmeta │ │ │ │triggerreason │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │dependson │buildmeta │ │ │ │dependson │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │buildhistory │buildmeta │ │ │ │history │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │jobhistory │buildmeta │ │ │ │jobhistory │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │info │ │not needed anymore │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │getbinaries │binaries get │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │wipebinaries │binaries wipe │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │list --binaries │binaries list │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │search --binary │binaries │ │ │ │search │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │bugowner │ │no real replacement use person │ │ │ │maintainer -b (if we support this) │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │maintainer │person │ │ │ │maintainer │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │maintainer project │person add │ │ │--add user --role role│api://project │ │ │ │role user │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │maintainer project │person delete │ │ │--delete user │api://project │ │ │ │user │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │whois │person meta │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │meta user │person meta │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │cat/less http://api/ │ │ │ │source/project/package│ │not needed (IMHO) │ │/file │ │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │repairlink │repair link │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │repairwc │repair wc │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │signkey │signkey │it's not context-sensitive anymore │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │rremove │ │do we really need this? │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │aggregatepac │aggregate │ │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │ │ │meta should display the xml in a nice │ │develproject │meta │way so that it's easy to see whether a │ │ │ │develprj is defined or not │ ├──────────────────────┼──────────────┼───────────────────────────────────────┤ │repositories │meta │meta should display the xml in a nice │ │ │ │way so that all repos are displayed │ └──────────────────────┴──────────────┴───────────────────────────────────────┘
new commandline user interface
init
┌────┬──────┬──────┬──────┬─────────────────────┬────┐ │cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────┼──────┼──────┼──────┼─────────────────────┼────┤ │init│ │ │ │api://project │ │ ├────┼──────┼──────┼──────┼─────────────────────┼────┤ │init│ │ │ │api://project/package│ │ └────┴──────┴──────┴──────┴─────────────────────┴────┘
list
┌───┬──────┬─────┬─────┬────────────────────┬─────────────────────────────────┐ │cmd│subcmd│ prj │ pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├───┼──────┼─────┼─────┼────────────────────┼─────────────────────────────────┤ │ls │ │x │ │ │list all remote packages for the │ │ │ │ │ │ │wc project │ ├───┼──────┼─────┼─────┼────────────────────┼─────────────────────────────────┤ │ls │ │ │x │ │list all remote files for the wc │ │ │ │ │ │ │package │ ├───┼──────┼─────┼─────┼────────────────────┼─────────────────────────────────┤ │ls │ │ │ │api:// │ │ ├───┼──────┼─────┼─────┼────────────────────┼─────────────────────────────────┤ │ls │ │ │ │api://project │ │ ├───┼──────┼─────┼─────┼────────────────────┼─────────────────────────────────┤ │ls │ │ │ │api://project/ │ │ │ │ │ │ │package │ │ ├───┼──────┼─────┼─────┼────────────────────┼─────────────────────────────────┤ │ls │ │ │ │api://project/ │just for backward compatibility │ │ │ │ │ │package/file │ │ └───┴──────┴─────┴─────┴────────────────────┴─────────────────────────────────┘
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│ │ └────┴──────┴──────┴──────┴──────────────────────┴────────────────────────┘
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 │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│set │ │ │api://project │set attribute to newval │ │ │ │ │ │attribute newval │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│create│ │ │api://project │create new attribute │ │ │ │ │ │attribute │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│delete│ │ │api://project │delete attribute │ │ │ │ │ │attribute │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│list │ │ │api://project/ │show all attributes │ │ │ │ │ │package │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │ │ │ │ │api://project/ │show all attributes - /binary │ │attribute│list │ │ │package/binary │works for all commands below, │ │ │ │ │ │ │too │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│list │ │ │api://project/ │show specific attribute │ │ │ │ │ │package attribute │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │ │ │ │ │api://project/ │ │ │attribute│set │ │ │package attribute │set attribute to newval │ │ │ │ │ │newval │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│create│ │ │api://project/ │create new attribute │ │ │ │ │ │package attribute │ │ ├─────────┼──────┼───┼───┼───────────────────┼────────────────────────────────┤ │attribute│delete│ │ │api://project/ │delete attribute │ │ │ │ │ │package attribute │ │ └─────────┴──────┴───┴───┴───────────────────┴────────────────────────────────┘
request
┌───────┬─────────┬───┬───┬─────────────────┬─────────────────────────────────┐ │ cmd │ subcmd │prj│pkg│ params/opts │ note │ │ │ │wc │wc │ │ │ ├───────┴─────────┴───┴───┴─────────────────┴─────────────────────────────────┤ │request is not context sensitive │ ├───────┬─────────┬───┬───┬─────────────────┬─────────────────────────────────┤ │ │ │ │ │--submit api:// │ │ │request│create │ │ │project/package │ │ │ │ │ │ │api://tgt_projet/│ │ │ │ │ │ │<package> │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │ │ │ │ │--submit api:// │ │ │request│create │ │ │project/package │ │ │ │ │ │ │api://tgt_projet/│ │ │ │ │ │ │<package> │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │ │ │ │ │--changedevel │ │ │ │ │ │ │api://project/ │ │ │request│create │ │ │package api:// │ │ │ │ │ │ │tgt_projet/ │ │ │ │ │ │ │<package> │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │ │ │ │ │--role role user │ │ │request│create │ │ │api://project/ │ │ │ │ │ │ │<package> │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │ │ │ │ │--grouprole role │ │ │request│create │ │ │group api:// │ │ │ │ │ │ │project/<package>│ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │ │ │ │ │--bugowner user │alternatively we treat bugowner │ │request│create │ │ │api://project/ │as a "role" and use --role │ │ │ │ │ │<package> │bugowner... │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│create │ │ │--delete api:// │ │ │ │ │ │ │project/<package>│ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│list │ │ │api://<project>/ │list all/project/package requests│ │ │ │ │ │<package> │ │ ├───────┴─────────┴───┴───┴─────────────────┴─────────────────────────────────┤ │in the following we support both: "api://id" and "id" (if the latter format │ │is specified the default apiurl is used - regardless if the cmd is executed │ │in a wc) │ ├───────┬─────────┬───┬───┬─────────────────┬─────────────────────────────────┤ │ │ │ │ │ │apart from --brief also support │ │request│show │ │ │api://id │--log which just shows the │ │ │ │ │ │ │statehistory + current state │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│supersede│ │ │api://id api:// │ │ │ │ │ │ │supersede_id │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│accept │ │ │api://id │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│decline │ │ │api://id │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│revoke │ │ │api://id │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│reopen │ │ │api://id │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │request│wipe │ │ │api://id │ │ ├───────┼─────────┼───┼───┼─────────────────┼─────────────────────────────────┤ │ │ │ │ │ │if the package's package belongs │ │ │ │ │ │ │to the wc's project the package │ │request│checkout │(x)│ │api://id │will be added to this project (if│ │ │ │ │ │ │it already exists an error will │ │ │ │ │ │ │be printed) │ └───────┴─────────┴───┴───┴─────────────────┴─────────────────────────────────┘
submitrequest
┌─────────────┬──────┬───┬───┬────────────────────┬───────────────────────────┐ │ cmd │subcmd│prj│pkg│ params/opts │ note │ │ │ │wc │wc │ │ │ ├─────────────┼──────┼───┼───┼────────────────────┼───────────────────────────┤ │ │ │ │ │ │semantic change: creates a │ │submitrequest│ │x │ │ │sr for all local packages │ │ │ │ │ │ │(instead of all remote) │ ├─────────────┼──────┼───┼───┼────────────────────┼───────────────────────────┤ │submitrequest│ │ │x │ │wc has to be a source link │ ├─────────────┼──────┼───┼───┼────────────────────┼───────────────────────────┤ │submitrequest│ │ │x │api://tgt_project/ │ │ │ │ │ │ │<tgt_package> │ │ ├─────────────┼──────┼───┼───┼────────────────────┼───────────────────────────┤ │ │ │ │ │api://project/ │ │ │submitrequest│ │ │ │package api:// │ │ │ │ │ │ │tgt_project/ │ │ │ │ │ │ │<tgt_package> │ │ └─────────────┴──────┴───┴───┴────────────────────┴───────────────────────────┘
review
┌──────┬─────────┬───┬───┬───────────────────────┬────────────────────────────┐ │ cmd │ subcmd │prj│pkg│ params/opts │ note │ │ │ │wc │wc │ │ │ ├──────┼─────────┼───┼───┼───────────────────────┼────────────────────────────┤ │review│accept │ │ │api://id │ │ ├──────┼─────────┼───┼───┼───────────────────────┼────────────────────────────┤ │review│decline │ │ │api://id │ │ ├──────┼─────────┼───┼───┼───────────────────────┼────────────────────────────┤ │review│reopen │ │ │api://id │ │ ├──────┼─────────┼───┼───┼───────────────────────┼────────────────────────────┤ │review│susersede│ │ │api://id api:// │ │ │ │ │ │ │supsersede_id │ │ ├──────┼─────────┼───┼───┼───────────────────────┼────────────────────────────┤ │ │ │ │ │api://id --user user │ │ │review│add │ │ │--group group --package│at least one option is │ │ │ │ │ │package --project │required │ │ │ │ │ │project │ │ ├──────┼─────────┼───┼───┼───────────────────────┼────────────────────────────┤ │ │ │ │ │ │just for convenience; │ │review│list │ │ │api://<project>/ │"request list --state │ │ │ │ │ │<package> │review" should lead to the │ │ │ │ │ │ │same result │ └──────┴─────────┴───┴───┴───────────────────────┴────────────────────────────┘
link
┌────┬──────┬─────┬─────┬────────────────────────────────────────────────┬────┐ │cmd │subcmd│ prj │ pkg │ params/opts │note│ │ │ │ wc │ wc │ │ │ ├────┼──────┼─────┼─────┼────────────────────────────────────────────────┼────┤ │link│ │ │ │api://link_project api://project │ │ ├────┼──────┼─────┼─────┼────────────────────────────────────────────────┼────┤ │link│ │ │ │api://link_project/link_package api://project/& │ │ │ │ │ │ │tl;package> │ │ └────┴──────┴─────┴─────┴────────────────────────────────────────────────┴────┘
copy
┌────┬──────┬────┬────┬─────────────────────────────────────────┬─────────────┐ │cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├────┼──────┼────┼────┼─────────────────────────────────────────┼─────────────┤ │copy│ │ │ │api://copy_project api://project │could be │ │ │ │ │ │ │supported │ ├────┼──────┼────┼────┼─────────────────────────────────────────┼─────────────┤ │copy│ │ │ │api://copy_project/copy_package api:// │ │ │ │ │ │ │project/&tl;package> │ │ └────┴──────┴────┴────┴─────────────────────────────────────────┴─────────────┘
maintenance
┌───────────┬──────────────┬────┬────┬────────────────────┬────────────────────┐ │ cmd │ subcmd │prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├───────────┼──────────────┼────┼────┼────────────────────┼────────────────────┤ │maintenance│releaserequest│x │ │ │ │ ├───────────┼──────────────┼────┼────┼────────────────────┼────────────────────┤ │maintenance│releaserequest│ │ │api://project │ │ ├───────────┼──────────────┼────┼────┼────────────────────┼────────────────────┤ │maintenance│createincident│ │ │<api://project> │ │ ├───────────┼──────────────┼────┼────┼────────────────────┼────────────────────┤ │maintenance│request │ │ │api://project <api:/│ │ │ │ │ │ │/tgt_project> │ │ ├───────────┼──────────────┼────┼────┼────────────────────┼────────────────────┤ │maintenance│branch │ │ │package │XXX: this voilates │ │ │ │ │ │<tgt_project> │the url schema │ └───────────┴──────────────┴────┴────┴────────────────────┴────────────────────┘
branch
┌──────┬──────┬─────┬─────┬──────────────────────────────────────────────┬────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │note│ │ │ │ wc │ wc │ │ │ ├──────┼──────┼─────┼─────┼──────────────────────────────────────────────┼────┤ │branch│ │ │ │api://project/package <api://tgt_project/ │ │ │ │ │ │ │tgt_package> │ │ └──────┴──────┴─────┴─────┴──────────────────────────────────────────────┴────┘
undelete
┌────────┬──────┬──────┬──────┬───────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────────┼──────┼──────┼──────┼───────────────────────┼────┤ │undelete│ │ │ │api://project/<package>│ │ └────────┴──────┴──────┴──────┴───────────────────────┴────┘
delete
┌──────┬──────┬─────┬─────┬────────────────────┬──────────────────────────────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────┼──────┼─────┼─────┼────────────────────┼──────────────────────────────┤ │delete│ │ │ │api://project/ │multiple arguments can be │ │ │ │ │ │<package> │specified │ ├──────┼──────┼─────┼─────┼────────────────────┼──────────────────────────────┤ │delete│ │ │ │/path/to/package │ │ ├──────┼──────┼─────┼─────┼────────────────────┼──────────────────────────────┤ │delete│ │ │ │/path/to/file │ │ └──────┴──────┴─────┴─────┴────────────────────┴──────────────────────────────┘
diff
┌────┬──────┬────┬────┬──────────────────────────────────────┬─────────────────┐ │cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │x │ │ │ │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │ │x │ │ │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │ │ │/path/to/file │multiple args are│ │ │ │ │ │ │supported │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │ │ │/path/to/package │ │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │ │ │/path/to/project │ │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │ │ │api://project/package │ │ ├────┼──────┼────┼────┼──────────────────────────────────────┼─────────────────┤ │diff│ │ │ │api://project/package api:// │ │ │ │ │ │ │original_project/original_package │ │ └────┴──────┴────┴────┴──────────────────────────────────────┴─────────────────┘
checkout
┌────────┬──────┬────┬────┬─────────────────┬─────────────────────────────────┐ │ cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├────────┼──────┼────┼────┼─────────────────┼─────────────────────────────────┤ │checkout│ │ │ │api://project/ │checking out a file is not │ │ │ │ │ │<package> │supported anymore │ ├────────┼──────┼────┼────┼─────────────────┼─────────────────────────────────┤ │checkout│ │x │ │package │adds the package to the wc │ ├────────┼──────┼────┼────┼─────────────────┼─────────────────────────────────┤ │checkout│ │x │ │package │adds the package to the wc │ └────────┴──────┴────┴────┴─────────────────┴─────────────────────────────────┘
status
┌──────┬──────┬─────┬─────┬───────────────────────────┬────────────────────────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────────┼────────────────────────┤ │status│ │x │ │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────────┼────────────────────────┤ │status│ │ │x │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────────┼────────────────────────┤ │status│ │ │ │/path/to/ │multiple arguments are │ │ │ │ │ │project_or_package_or_file │supported │ └──────┴──────┴─────┴─────┴───────────────────────────┴────────────────────────┘
add
┌───┬──────┬──────┬──────┬────────────────────┬───────────────────────────────┐ │cmd│subcmd│prj wc│pkg wc│ params/opts │ note │ ├───┼──────┼──────┼──────┼────────────────────┼───────────────────────────────┤ │add│ │ │ │/path/to/dir_or_file│multiple arguments are │ │ │ │ │ │ │supported │ ├───┼──────┼──────┼──────┼────────────────────┼───────────────────────────────┤ │add│ │ │ │URL │create a _service file │ └───┴──────┴──────┴──────┴────────────────────┴───────────────────────────────┘
addremove
┌─────────┬──────┬──────┬──────┬───────────────┬──────────────────────────────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │ note │ ├─────────┼──────┼──────┼──────┼───────────────┼──────────────────────────────┤ │addremove│ │x │ │ │ │ ├─────────┼──────┼──────┼──────┼───────────────┼──────────────────────────────┤ │addremove│ │ │x │ │ │ ├─────────┼──────┼──────┼──────┼───────────────┼──────────────────────────────┤ │addremove│ │ │ │/path/to/ │multiple arguments are │ │ │ │ │ │package │supported │ └─────────┴──────┴──────┴──────┴───────────────┴──────────────────────────────┘
commit
┌──────┬──────┬─────┬─────┬───────────────────────────┬────────────────────────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────────┼────────────────────────┤ │commit│ │x │ │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────────┼────────────────────────┤ │commit│ │ │x │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────────┼────────────────────────┤ │commit│ │ │ │/path/to/ │multiple arguments are │ │ │ │ │ │project_or_package_or_file │supported │ └──────┴──────┴─────┴─────┴───────────────────────────┴────────────────────────┘
update
┌──────┬──────┬─────┬─────┬───────────────────────┬───────────────────────────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────┼───────────────────────────┤ │update│ │x │ │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────┼───────────────────────────┤ │update│ │ │x │ │ │ ├──────┼──────┼─────┼─────┼───────────────────────┼───────────────────────────┤ │update│ │ │ │/path/to/ │multiple arguments are │ │ │ │ │ │project_or_package │supported │ └──────┴──────┴─────┴─────┴───────────────────────┴───────────────────────────┘
resolved
┌────────┬──────┬──────┬──────┬─────────────┬────────────────────────────────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │ note │ ├────────┼──────┼──────┼──────┼─────────────┼────────────────────────────────┤ │resolved│ │ │ │/path/to/file│multiple arguments are supported│ └────────┴──────┴──────┴──────┴─────────────┴────────────────────────────────┘
distributions
┌─────────────┬──────┬──────┬──────┬───────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│params/opts│note│ ├─────────────┼──────┼──────┼──────┼───────────┼────┤ │distributions│ │ │ │api:// │ │ └─────────────┴──────┴──────┴──────┴───────────┴────┘
results
┌───────┬──────┬──────┬──────┬───────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├───────┼──────┼──────┼──────┼───────────────────────┼────┤ │results│ │x │ │ │ │ ├───────┼──────┼──────┼──────┼───────────────────────┼────┤ │results│ │ │x │ │ │ ├───────┼──────┼──────┼──────┼───────────────────────┼────┤ │results│ │ │ │api://project/<package>│ │ └───────┴──────┴──────┴──────┴───────────────────────┴────┘
buildlog if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌────────┬──────┬──────┬──────┬─────────────────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────────┼──────┼──────┼──────┼─────────────────────────────────┼────┤ │buildlog│ │ │x │<repo/arch> │ │ ├────────┼──────┼──────┼──────┼─────────────────────────────────┼────┤ │buildlog│ │ │x │<repo/arch> --local │ │ ├────────┼──────┼──────┼──────┼─────────────────────────────────┼────┤ │buildlog│ │ │ │api://project/package <repo/arch>│ │ └────────┴──────┴──────┴──────┴─────────────────────────────────┴────┘
buildmeta if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌─────────┬─────────────┬───┬───┬───────────────┬─────────────────────────────┐ │ cmd │ subcmd │prj│pkg│ params/opts │ note │ │ │ │wc │wc │ │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │ │distingiush between repo/arch│ │buildmeta│info │ │x │<repo/arch> │build_descr, /arch │ │ │ │ │ │<build_descr> │build_descr via the file │ │ │ │ │ │ │extension of build_descr │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │api://project/ │distingiush between repo/arch│ │buildmeta│info │ │ │package <repo/ │build_descr, /arch │ │ │ │ │ │arch> │build_descr via the file │ │ │ │ │ │<build_descr> │extension of build_descr │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│config │ │x │<repo/arch> │ │ │ │ │ │ │<build_descr> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│config │ │ │api://project/ │ │ │ │ │ │ │package <repo> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│triggerreason│ │x │<repo/arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │api://project/ │ │ │buildmeta│triggerreason│ │ │package <repo/ │ │ │ │ │ │ │arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│dependson │ │x │<repo/arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │api://project/ │ │ │buildmeta│dependson │ │ │package <repo/ │ │ │ │ │ │ │arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│log │ │x │<repo/arch> │same as buildlog (just for │ │ │ │ │ │ │consistency) │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│log │ │x │<repo/arch> │same as buildlog (just for │ │ │ │ │ │--local │consistency) │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │api://project/ │same as buildlog (just for │ │buildmeta│log │ │ │package <repo/ │consistency) │ │ │ │ │ │arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│history │ │x │<repo/arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │api://project/ │ │ │buildmeta│history │ │ │package <repo/ │ │ │ │ │ │ │arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│jobhistory │ │x │<repo/arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │buildmeta│jobhistory │x │ │<repo/arch> │ │ ├─────────┼─────────────┼───┼───┼───────────────┼─────────────────────────────┤ │ │ │ │ │api://project/ │ │ │buildmeta│jobhistory │ │ │<package> <repo│ │ │ │ │ │ │/arch> │ │ └─────────┴─────────────┴───┴───┴───────────────┴─────────────────────────────┘
build if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌─────┬──────┬──────┬──────┬─────────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├─────┼──────┼──────┼──────┼─────────────────────────┼────┤ │build│ │ │x │<repo/arch> <build_descr>│ │ └─────┴──────┴──────┴──────┴─────────────────────────┴────┘
chroot if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌──────┬──────┬────┬────┬──────────────────┬──────────────────────────────────┐ │ cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────┼──────┼────┼────┼──────────────────┼──────────────────────────────────┤ │chroot│ │ │x │<repo/arch> │build_descr is not needed for the │ │ │ │ │ │<build_descr> │command itself │ └──────┴──────┴────┴────┴──────────────────┴──────────────────────────────────┘
log
┌───┬──────┬──────┬──────┬───────────────────────┬────┐ │cmd│subcmd│prj wc│pkg wc│ params/opts │note│ ├───┼──────┼──────┼──────┼───────────────────────┼────┤ │log│ │x │ │ │ │ ├───┼──────┼──────┼──────┼───────────────────────┼────┤ │log│ │ │x │ │ │ ├───┼──────┼──────┼──────┼───────────────────────┼────┤ │log│ │ │ │api://project/<package>│ │ └───┴──────┴──────┴──────┴───────────────────────┴────┘
service
┌───────┬───────────┬──────┬──────┬─────────────────────┬────┐ │ cmd │ subcmd │prj wc│pkg wc│ params/opts │note│ ├───────┼───────────┼──────┼──────┼─────────────────────┼────┤ │service│run │ │x │<service_name> │ │ ├───────┼───────────┼──────┼──────┼─────────────────────┼────┤ │service│disabledrun│ │x │ │ │ ├───────┼───────────┼──────┼──────┼─────────────────────┼────┤ │service│remoterun │ │ │api://project/package│ │ └───────┴───────────┴──────┴──────┴─────────────────────┴────┘
abortbuild if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌──────────┬──────┬────┬────┬────────────────────────┬────────────────────────┐ │ cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├──────────┼──────┼────┼────┼────────────────────────┼────────────────────────┤ │abortbuild│ │x │ │<repo/arch> │to abort all builds │ │ │ │ │ │ │specifiy --all │ ├──────────┼──────┼────┼────┼────────────────────────┼────────────────────────┤ │abortbuild│ │ │x │<repo/arch> │to abort all builds │ │ │ │ │ │ │specifiy --all │ ├──────────┼──────┼────┼────┼────────────────────────┼────────────────────────┤ │abortbuild│ │ │ │api://project/<package> │to abort all builds │ │ │ │ │ │<repo/arch> │specifiy --all │ └──────────┴──────┴────┴────┴────────────────────────┴────────────────────────┘
rebuild if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌───────┬──────┬────┬────┬────────────────────────┬───────────────────────────┐ │ cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├───────┼──────┼────┼────┼────────────────────────┼───────────────────────────┤ │rebuild│ │x │ │<repo/arch> │to rebuild all packages │ │ │ │ │ │ │specifiy --all │ ├───────┼──────┼────┼────┼────────────────────────┼───────────────────────────┤ │rebuild│ │ │x │<repo/arch> │to rebuild all packages │ │ │ │ │ │ │specifiy --all │ ├───────┼──────┼────┼────┼────────────────────────┼───────────────────────────┤ │rebuild│ │ │ │api://project/<package> │to rebuild all packages │ │ │ │ │ │<repo/arch> │specifiy --all │ └───────┴──────┴────┴────┴────────────────────────┴───────────────────────────┘
rebuild if repo/arch is not specified the config values will be used (default_repo, default_arch)
┌────────┬──────┬────┬────┬─────────────────────────┬─────────────────────────┐ │ cmd │subcmd│prj │pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│get │x │ │<repo/arch> │to get all binaries │ │ │ │ │ │ │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│get │ │x │<repo/arch> │to get all binaries │ │ │ │ │ │ │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│get │ │ │api://project/<package> │to get all binaries │ │ │ │ │ │<repo/arch> │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│list │x │ │<repo/arch> │to list all binaries │ │ │ │ │ │ │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│list │ │x │<repo/arch> │to list all binaries │ │ │ │ │ │ │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│list │ │ │api://project/<package> │to list all binaries │ │ │ │ │ │<repo/arch> │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│wipe │x │ │<repo/arch> │to wipe all binaries │ │ │ │ │ │ │specifiy --all │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│search│ │ │api://<project> │ │ │ │ │ │ │search_term │ │ ├────────┼──────┼────┼────┼─────────────────────────┼─────────────────────────┤ │binaries│wipe │ │ │api://project/<package> │to wipe all binaries │ │ │ │ │ │<repo/arch> │specifiy --all │ └────────┴──────┴────┴────┴─────────────────────────┴─────────────────────────┘
my
┌───┬──────────────┬──────┬──────┬───────────┬────┐ │cmd│ subcmd │prj wc│pkg wc│params/opts│note│ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │requests │ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │submitrequests│ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │projects │ │ │ │ │ ├───┼──────────────┼──────┼──────┼───────────┼────┤ │my │packages │ │ │ │ │ └───┴──────────────┴──────┴──────┴───────────┴────┘
search
┌──────┬──────┬──────┬──────┬───────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│params/opts│note│ ├──────┼──────┼──────┼──────┼───────────┼────┤ │search│ │ │ │search_term│ │ └──────┴──────┴──────┴──────┴───────────┴────┘
importsrcpkg
┌────────────┬──────┬──────┬──────┬─────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────────────┼──────┼──────┼──────┼─────────────┼────┤ │importsrcpkg│ │x │ │/path/to/srpm│ │ └────────────┴──────┴──────┴──────┴─────────────┴────┘
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> │ │ └──────┴──────────┴────┴────┴───────────────────────┴─────────────────────────┘
cat
┌───┬──────┬──────┬──────┬──────────────────────────┬────┐ │cmd│subcmd│prj wc│pkg wc│ params/opts │note│ ├───┼──────┼──────┼──────┼──────────────────────────┼────┤ │cat│ │ │ │api://project/package/file│ │ └───┴──────┴──────┴──────┴──────────────────────────┴────┘
less
┌───┬──────┬──────┬──────┬──────────────────────────┬────┐ │cmd│subcmd│prj wc│pkg wc│ params/opts │note│ ├───┼──────┼──────┼──────┼──────────────────────────┼────┤ │cat│ │ │ │api://project/package/file│ │ └───┴──────┴──────┴──────┴──────────────────────────┴────┘
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 │ │ │ └──────┴──────┴─────┴─────┴──────────────────────────────────────────────┴────┘
pull
┌────┬──────┬──────┬──────┬───────────┬────┐ │cmd │subcmd│prj wc│pkg wc│params/opts│note│ ├────┼──────┼──────┼──────┼───────────┼────┤ │pull│ │ │x │ │ │ └────┴──────┴──────┴──────┴───────────┴────┘
signkey
┌───────┬──────┬──────┬──────┬─────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├───────┼──────┼──────┼──────┼─────────────┼────┤ │signkey│ │ │ │api://project│ │ └───────┴──────┴──────┴──────┴─────────────┴────┘
vc
┌───┬──────┬──────┬──────┬───────────┬────┐ │cmd│subcmd│prj wc│pkg wc│params/opts│note│ ├───┼──────┼──────┼──────┼───────────┼────┤ │vc │ │ │ │ │ │ └───┴──────┴──────┴──────┴───────────┴────┘
mv
┌───┬──────┬─────┬─────┬──────────────────┬───────────────────────────────────┐ │cmd│subcmd│ prj │ pkg │ params/opts │ note │ │ │ │ wc │ wc │ │ │ ├───┼──────┼─────┼─────┼──────────────────┼───────────────────────────────────┤ │mv │ │ │x │filename │should we support this for │ │ │ │ │ │new_filename │packages, too? │ └───┴──────┴─────┴─────┴──────────────────┴───────────────────────────────────┘
config
┌──────┬──────┬──────┬──────┬────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├──────┼──────┼──────┼──────┼────────────────────┼────┤ │config│ │ │ │section option │ │ ├──────┼──────┼──────┼──────┼────────────────────┼────┤ │config│ │ │ │section option value│ │ └──────┴──────┴──────┴──────┴────────────────────┴────┘
revert
┌──────┬──────┬──────┬──────┬─────────────┬────────────────────────────────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │ note │ ├──────┼──────┼──────┼──────┼─────────────┼────────────────────────────────┤ │revert│ │ │x │ │ │ ├──────┼──────┼──────┼──────┼─────────────┼────────────────────────────────┤ │revert│ │ │ │/path/to/file│multiple arguments are supported│ └──────┴──────┴──────┴──────┴─────────────┴────────────────────────────────┘
api
┌───┬──────┬──────┬──────┬───────────────────────┬────┐ │cmd│subcmd│prj wc│pkg wc│ params/opts │note│ ├───┼──────┼──────┼──────┼───────────────────────┼────┤ │api│ │ │ │api://path/to/something│ │ └───┴──────┴──────┴──────┴───────────────────────┴────┘
aggregate
┌─────────┬──────┬─────┬─────┬───────────────────────────────────────────┬────┐ │ cmd │subcmd│ prj │ pkg │ params/opts │note│ │ │ │ wc │ wc │ │ │ ├─────────┼──────┼─────┼─────┼───────────────────────────────────────────┼────┤ │aggregate│ │ │ │api://project/package api://tgt_project/ │ │ │ │ │ │ │<tgt_packge> │ │ └─────────┴──────┴─────┴─────┴───────────────────────────────────────────┴────┘
mkpac
┌─────┬──────┬──────┬──────┬────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│params/opts │note│ ├─────┼──────┼──────┼──────┼────────────┼────┤ │mkpac│ │x │ │package_name│ │ └─────┴──────┴──────┴──────┴────────────┴────┘
setlinkrev
┌──────────┬──────┬──────┬──────┬───────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├──────────┼──────┼──────┼──────┼───────────────────────┼────┤ │setlinkrev│ │ │x │ │ │ ├──────────┼──────┼──────┼──────┼───────────────────────┼────┤ │setlinkrev│ │ │ │api://project/<package>│ │ └──────────┴──────┴──────┴──────┴───────────────────────┴────┘
linktobranch
┌────────────┬──────┬──────┬──────┬─────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────────────┼──────┼──────┼──────┼─────────────────────┼────┤ │linktobranch│ │ │x │ │ │ ├────────────┼──────┼──────┼──────┼─────────────────────┼────┤ │linktobranch│ │ │ │api://project/package│ │ └────────────┴──────┴──────┴──────┴─────────────────────┴────┘
detachbranch
┌────────────┬──────┬──────┬──────┬─────────────────────┬────┐ │ cmd │subcmd│prj wc│pkg wc│ params/opts │note│ ├────────────┼──────┼──────┼──────┼─────────────────────┼────┤ │detachbranch│ │ │x │ │ │ ├────────────┼──────┼──────┼──────┼─────────────────────┼────┤ │detachbranch│ │ │ │api://project/package│ │ └────────────┴──────┴──────┴──────┴─────────────────────┴────┘
-- With best regards, Carsten Hoeger
On Wednesday 08 June 2011 10:12:55 Carsten Hoeger wrote:
On Mon, May 23, Marcus Hüwe wrote:
Please keep in mind, that osc is an api to access obs. People might use osc to integrate with obs as I do. When you break the osc api at least for me that will result in a bigger mess. That might be valid for others, too.
Instead of breaking the api of the existing osc, I'd suggest to create a new osc (e.g. osc2 or whatever) and keep the old one for a while. That's exactly what we're up to. For at least a while, this will be an independent effort. -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
participants (7)
-
Adrian Schröter -
Carsten Hoeger -
Johannes Meixner -
Juergen Weigert -
Marcus Hüwe -
Sascha Peilicke -
Vincent Untz