[opensuse-buildservice] new "osc request" handling
Hello, Juergen, Michael, Klaas and me sit together to discuss how should we design the osc request interface. The problem is that osc only knows "submitreq" command so far. But now we have two more requests, delete and devel_change requests. And more will come. This new design will not be compatible with the current "osc submitreq" and we will most likely not be able to support the old commands in the same syntax anymore. But we think it is better to do this change anyway to have it more consistent. Our idea are the following commands for osc. Please tell us your opinion about it. (We will implement this tomorrow if no new problems pop up). Create new requests: ================ osc sr osc sr PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] osc submitrequest osc submitrequest PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] osc dr PROJECT [PACKAGE] osc deleterequest PROJECT [PACKAGE osc cr PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc changedevelrequest PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] Note: So far we had "osc submitreq create ...", the create will get dropped. Modify existing requests: ========================= osc request accept ID osc request decline ID osc request revoke ID (drops the request, but it is still showable) osc request wipe ID (removes the requst forever) (optional "rq" for "request") Show existing requests: ======================= osc list # list requests (maybe we can make this one obsolete) osc request # list requests osc request ID # show request with $ID Open questions are: * How to support requests with multiple actions later ? ( osc submitreq PROJECT PACKAGE , deletereq PROJECT PACKAGE , deletereq . ) -- 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 2009-06-02 16:24:45 +0200, Adrian Schröter wrote:
Juergen, Michael, Klaas and me sit together to discuss how should we design the osc request interface. The problem is that osc only knows "submitreq" command so far. But now we have two more requests, delete and devel_change requests. And more will come.
This new design will not be compatible with the current "osc submitreq" and we will most likely not be able to support the old commands in the same syntax anymore. But we think it is better to do this change anyway to have it more consistent.
Our idea are the following commands for osc. Please tell us your opinion about it. (We will implement this tomorrow if no new problems pop up).
you are breaking the UI for no real reason. which is bad.
Create new requests: ================ osc sr osc sr PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] osc submitrequest osc submitrequest PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
osc dr PROJECT [PACKAGE] osc deleterequest PROJECT [PACKAGE
osc cr PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc changedevelrequest PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE]
inconsistent. see below
Note: So far we had "osc submitreq create ...", the create will get dropped.
Modify existing requests: =========================
osc request accept ID osc request decline ID osc request revoke ID (drops the request, but it is still showable) osc request wipe ID (removes the requst forever)
osc request deletion PROJECT [PACKAGE] osc request changedevel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc request submit PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] that way we can leave the old "osc sr" behavior in place as compat layer. we got this documented in many places, (Wiki, blog postings) and should not just break it in a rush (2days for such an intrusive change is a bit too short).
(optional "rq" for "request")
you also added osc req als alternative, which was used before to run api requests manually. will it would be confusing to keep both around. again breaking the UI.
Show existing requests: =======================
osc list # list requests (maybe we can make this one obsolete)
"osc request list" if at all. osc list is too unspecific and could confused as synonym for "osc ls".
osc request # list requests
it follows the REST style paradigm, might work. would need to see it in action i think
osc request ID
osc request show ID should still be provided. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Donnerstag, 4. Juni 2009 16:40:40 schrieb Marcus Rueckert:
On 2009-06-02 16:24:45 +0200, Adrian Schröter wrote:
Juergen, Michael, Klaas and me sit together to discuss how should we design the osc request interface. The problem is that osc only knows "submitreq" command so far. But now we have two more requests, delete and devel_change requests. And more will come.
This new design will not be compatible with the current "osc submitreq" and we will most likely not be able to support the old commands in the same syntax anymore. But we think it is better to do this change anyway to have it more consistent.
Our idea are the following commands for osc. Please tell us your opinion about it. (We will implement this tomorrow if no new problems pop up).
you are breaking the UI for no real reason. which is bad.
as written the reason is that "sr" would not able to handle delete or change devel requests. And we made also cleanups in other commands for this release, so better do a change at one step to get a consistent logic again.
Create new requests: ================ osc sr osc sr PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] osc submitrequest osc submitrequest PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
osc dr PROJECT [PACKAGE] osc deleterequest PROJECT [PACKAGE
osc cr PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc changedevelrequest PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE]
inconsistent. see below
Why is this inconsistent ? where is the conflict ?
Note: So far we had "osc submitreq create ...", the create will get dropped.
Modify existing requests: =========================
osc request accept ID osc request decline ID osc request revoke ID (drops the request, but it is still showable) osc request wipe ID (removes the requst forever)
osc request deletion PROJECT [PACKAGE] osc request changedevel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc request submit PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
could get implemented, yes. But deletion would be a special writing, while we use "delete" elsewhere. and "osc sr" is much shorter than "osc rq submit", important since it is an often use command.
that way we can leave the old "osc sr" behavior in place as compat layer. we got this documented in many places, (Wiki, blog postings) and should not just break it in a rush (2days for such an intrusive change is a bit too short).
not really, or at least with problems when you want to deal with the new requests submitted by someone else.
(optional "rq" for "request")
you also added osc req als alternative, which was used before to run api requests manually. will it would be confusing to keep both around. again breaking the UI.
yes, but we never promised to keep it forever. We have a stable API instead if you rely on automatism. (where we did also a change due to problems with request handling as discussed two weeks ago, introducing the actions for requests.)
Show existing requests: =======================
osc list # list requests (maybe we can make this one obsolete)
"osc request list" if at all. osc list is too unspecific and could confused as synonym for "osc ls".
it is "osc rq list" actually.
osc request # list requests
it follows the REST style paradigm, might work. would need to see it in action i think
that one is currently not implemented.
osc request ID
osc request show ID
yes, it is implemented this way. 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
On 2009-06-04 17:02:59 +0200, Adrian Schröter wrote:
Am Donnerstag, 4. Juni 2009 16:40:40 schrieb Marcus Rueckert:
On 2009-06-02 16:24:45 +0200, Adrian Schröter wrote:
Juergen, Michael, Klaas and me sit together to discuss how should we design the osc request interface. The problem is that osc only knows "submitreq" command so far. But now we have two more requests, delete and devel_change requests. And more will come.
This new design will not be compatible with the current "osc submitreq" and we will most likely not be able to support the old commands in the same syntax anymore. But we think it is better to do this change anyway to have it more consistent.
Our idea are the following commands for osc. Please tell us your opinion about it. (We will implement this tomorrow if no new problems pop up).
you are breaking the UI for no real reason. which is bad.
as written the reason is that "sr" would not able to handle delete or change devel requests.
it is not supposed to. osc sr create will only create submitrequests nothing more. all other options like accept/decline/revoke/show/wipe can just map through to their osc request equivalent. for creating delete/changedevel requests you have to use the new command. that way you even got a guidance towards the new command. maybe we should even add a warning when using the osc sr wrapper that the UI is deprecated and getting removed in the future. that gives people time to adapt scripts and themself.
And we made also cleanups in other commands for this release, so better do a change at one step to get a consistent logic again.
Create new requests: ================ osc sr osc sr PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] osc submitrequest osc submitrequest PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
osc dr PROJECT [PACKAGE] osc deleterequest PROJECT [PACKAGE
osc cr PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc changedevelrequest PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE]
inconsistent. see below
Why is this inconsistent ? where is the conflict ?
all other related commands are below osc request. e.g with the old osc you can do "osc sr help" and get all commands related to submitrequests. you should get the same with "osc rq help" moving the creation commands out of the scope makes this unnecessarily complex.
Note: So far we had "osc submitreq create ...", the create will get dropped.
Modify existing requests: =========================
osc request accept ID osc request decline ID osc request revoke ID (drops the request, but it is still showable) osc request wipe ID (removes the requst forever)
osc request deletion PROJECT [PACKAGE] osc request changedevel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc request submit PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
could get implemented, yes. But deletion would be a special writing, while we use "delete" elsewhere. and "osc sr" is much shorter than "osc rq submit", important since it is an often use command.
well. as i proposed keep the osc sr compat api. then you can easily do osc sr c(reate) <params> an "osc rq su <params>" is equally short (but a bit cryptic.:) (it follows a similar UI as "ip" from iproute2 here. as soon as a subcommand can be match without ambiguity it can be used.) maybe as "osc rq sr <params>"
that way we can leave the old "osc sr" behavior in place as compat layer. we got this documented in many places, (Wiki, blog postings) and should not just break it in a rush (2days for such an intrusive change is a bit too short).
not really, or at least with problems when you want to deal with the new requests submitted by someone else.
well. i am not talking about the server side api. just the client side UI. and i think that can be covered.
(optional "rq" for "request")
you also added osc req als alternative, which was used before to run api requests manually. will it would be confusing to keep both around. again breaking the UI.
yes, but we never promised to keep it forever. We have a stable API instead if you rely on automatism.
well we want to handle the UI as carefully as an api. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Donnerstag, 4. Juni 2009 18:20:12 schrieb Marcus Rueckert:
On 2009-06-04 17:02:59 +0200, Adrian Schröter wrote:
Am Donnerstag, 4. Juni 2009 16:40:40 schrieb Marcus Rueckert:
On 2009-06-02 16:24:45 +0200, Adrian Schröter wrote:
Juergen, Michael, Klaas and me sit together to discuss how should we design the osc request interface. The problem is that osc only knows "submitreq" command so far. But now we have two more requests, delete and devel_change requests. And more will come.
This new design will not be compatible with the current "osc submitreq" and we will most likely not be able to support the old commands in the same syntax anymore. But we think it is better to do this change anyway to have it more consistent.
Our idea are the following commands for osc. Please tell us your opinion about it. (We will implement this tomorrow if no new problems pop up).
you are breaking the UI for no real reason. which is bad.
as written the reason is that "sr" would not able to handle delete or change devel requests.
it is not supposed to. osc sr create will only create submitrequests nothing more. all other options like accept/decline/revoke/show/wipe can just map through to their osc request equivalent.
you will need to double the code for this, because there are conflicts like "delete". And all other consolidations like the pac/pkg to a common one, delete* and others we did would not be valid by that argument. But we (multiple contributors) fixed inconsistencies this time to clean up the interface. If we don't do this we will end up in a hughe list of commands where many of them do similar things, but no one understands the differences anymore. And we can't select logic names anymore since they reserved.
for creating delete/changedevel requests you have to use the new command. that way you even got a guidance towards the new command.
maybe we should even add a warning when using the osc sr wrapper that the UI is deprecated and getting removed in the future.
that gives people time to adapt scripts and themself.
Are there really that many people who use osc via scripts ? Having a usable interface is IMHO more important in the long run.
And we made also cleanups in other commands for this release, so better do a change at one step to get a consistent logic again.
Create new requests: ================ osc sr osc sr PROJECT PACKAGE DESTPROJECT [DESTPACKAGE] osc submitrequest osc submitrequest PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
osc dr PROJECT [PACKAGE] osc deleterequest PROJECT [PACKAGE
osc cr PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc changedevelrequest PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE]
inconsistent. see below
Why is this inconsistent ? where is the conflict ?
all other related commands are below osc request.
right, but these are common for all requests and not special for each kind. We also have not add, remove, ci and so on under a common command. Btw, there is still the open problem how to design the CLI for requests with multiple actions (for example multiple package submits and delete via one request). I would be happy if someone has a suggestion how to design this.
e.g with the old osc you can do "osc sr help" and get all commands related to submitrequests.
you should get the same with "osc rq help" moving the creation commands out of the scope makes this unnecessarily complex.
the help is more or less free text, we can add a reference there without problems.
Note: So far we had "osc submitreq create ...", the create will get dropped.
Modify existing requests: =========================
osc request accept ID osc request decline ID osc request revoke ID (drops the request, but it is still showable) osc request wipe ID (removes the requst forever)
osc request deletion PROJECT [PACKAGE] osc request changedevel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] osc request submit PROJECT PACKAGE DESTPROJECT [DESTPACKAGE]
could get implemented, yes. But deletion would be a special writing, while we use "delete" elsewhere. and "osc sr" is much shorter than "osc rq submit", important since it is an often use command.
well. as i proposed keep the osc sr compat api. then you can easily do osc sr c(reate) <params>
an "osc rq su <params>" is equally short (but a bit cryptic.:) (it follows a similar UI as "ip" from iproute2 here. as soon as a subcommand can be match without ambiguity it can be used.)
maybe as "osc rq sr <params>"
seriously, this does not look nice and usable. However, could some more people please add their opinions on this ? Otherwise we can discuss this forever, I think ;) When you want to play around how it works in real life, please use the osc from openSUSE:Tools:Unstable project. 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
On Thu, 4 Jun 2009, Adrian Schröter wrote:
Am Donnerstag, 4. Juni 2009 18:20:12 schrieb Marcus Rueckert:
On 2009-06-04 17:02:59 +0200, Adrian Schröter wrote:
Am Donnerstag, 4. Juni 2009 16:40:40 schrieb Marcus Rueckert:
On 2009-06-02 16:24:45 +0200, Adrian Schröter wrote:
Juergen, Michael, Klaas and me sit together to discuss how should we design the osc request interface. The problem is that osc only knows "submitreq" command so far. But now we have two more requests, delete and devel_change requests. And more will come.
This new design will not be compatible with the current "osc submitreq" and we will most likely not be able to support the old commands in the same syntax anymore. But we think it is better to do this change anyway to have it more consistent.
Our idea are the following commands for osc. Please tell us your opinion about it. (We will implement this tomorrow if no new problems pop up).
you are breaking the UI for no real reason. which is bad.
as written the reason is that "sr" would not able to handle delete or change devel requests.
it is not supposed to. osc sr create will only create submitrequests nothing more. all other options like accept/decline/revoke/show/wipe can just map through to their osc request equivalent.
you will need to double the code for this, because there are conflicts like "delete". And all other consolidations like the pac/pkg to a common one, delete* and others we did would not be valid by that argument. But we (multiple contributors) fixed inconsistencies this time to clean up the interface.
If we don't do this we will end up in a hughe list of commands where many of them do similar things, but no one understands the differences anymore. And we can't select logic names anymore since they reserved. ... Are there really that many people who use osc via scripts ? Having a usable interface is IMHO more important in the long run.
+1, I think if we are going to make changes now is the time to do it for both osc and the UI. We need to get it right now. I like what has been proposed. ...
I would be happy if someone has a suggestion how to design this.
Most of the stuff I have used has a Command Termination Character(CTC). For example in bash one can use the ";" exp $ cmd;cmd;cmd. So I would envision $ osc cmd<ctc>cmd<ctc>cmd What character to use I do not know. I just had surgery and I am not thinking really clearly, but this is something I feel is real important and some should be done now. It should not be postponed.
e.g with the old osc you can do "osc sr help" and get all commands related to submitrequests.
you should get the same with "osc rq help" moving the creation commands out of the scope makes this unnecessarily complex.
the help is more or less free text, we can add a reference there without problems. ... However, could some more people please add their opinions on this ? Otherwise we can discuss this forever, I think ;)
When you want to play around how it works in real life, please use the osc from openSUSE:Tools:Unstable project.
I agree. We really do need to do something. I think there is no better
time than the present.
--
Boyd Gerber
On 2009-06-04 14:40:02 -0600, Boyd Lynn Gerber wrote:
+1, I think if we are going to make changes now is the time to do it for both osc and the UI. We need to get it right now. I like what has been proposed.
osc is an user interface. user interface doesnt always mean "graphical". and the whole discussion was about osc not about the webclient or anything. and for a cmdline tool the important part are stable cmdline params/subcommands. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Friday 05 June 2009 00:25:13 Marcus Rueckert wrote:
On 2009-06-04 14:40:02 -0600, Boyd Lynn Gerber wrote:
+1, I think if we are going to make changes now is the time to do it for both osc and the UI. We need to get it right now. I like what has been proposed.
osc is an user interface. user interface doesnt always mean "graphical". and the whole discussion was about osc not about the webclient or anything. and for a cmdline tool the important part are stable cmdline params/subcommands.
well, I'd second that. Not that I like any of the osc cmdline syntax particularly ;) but at least I have my most common commands easily at hand after quite a while now, and I'd guess others have similarly invested time to find out ways to do the tasks they want to accomplish and how to express that with osc. Extending the interface by new methods (options, arguments, ...) is perfectly fine but I'd really ask to keep the current ones working for quite a while(1) probably with some reminder for the (updated/changed) new syntax, at best with a reminder that gives me a cut'n'paste full expansion of how to write my "oldish" command in a current way with all arguments already in place. There is always a learning curve when people start to do things and I think we agree that we want more people to use the buildservice and it's tools like osc. Changing some of the most common commands (and I think the submitreq is part of that set) will push many people back to the start of that curve. By abandoning interfaces now, the user will get the impression: "this worked yesterday but does not any longer, something is broken ...". After all we should not forget that for most users of the buildservice, the buildservice itself is just a method to get work done (change code, look at diffs, submit changes,...) and they don't really want to care about the technology or cleanlyness of a commandline interface. There are vaild reasons and technical neccessities to add and extend the interface, but up to now I don't see the reason to break things. just my 2 cents since you asked for comments ... ;) (1) thinking about it: would it be possible to hack up some statistic in the api to see which commands/variants are used frequently to get an idea when some possibly outdated interface is really "almost" not used anymore ? -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux MacBookRudi 2.6.30-rc6-git3-4-default #1 SMP 2009-05-25 14:11:59 +0200 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Freitag, 5. Juni 2009 01:33:02 schrieb Ruediger Oertel:
On Friday 05 June 2009 00:25:13 Marcus Rueckert wrote:
On 2009-06-04 14:40:02 -0600, Boyd Lynn Gerber wrote:
+1, I think if we are going to make changes now is the time to do it for both osc and the UI. We need to get it right now. I like what has been proposed.
osc is an user interface. user interface doesnt always mean "graphical". and the whole discussion was about osc not about the webclient or anything. and for a cmdline tool the important part are stable cmdline params/subcommands.
well, I'd second that. Not that I like any of the osc cmdline syntax particularly ;) but at least I have my most common commands easily at hand after quite a while now, and I'd guess others have similarly invested time to find out ways to do the tasks they want to accomplish and how to express that with osc.
Extending the interface by new methods (options, arguments, ...) is perfectly fine but I'd really ask to keep the current ones working for quite a while(1) probably with some reminder for the (updated/changed) new syntax, at best with a reminder that gives me a cut'n'paste full expansion of how to write my "oldish" command in a current way with all arguments already in place.
I completely agree to this, but the problem was that the old commands were inconsistent and blocking namespaces which could be used to make the interface better. Right now, I have no idea how to design the commands with keeping the old syntax and have a new working one. The suggestion of "osc rq submit" for the old "osc sr create" is possible, but I hope you agree that a simple "osc sr" for the same task would be much nicer. Also haveing "osc sr delete" and "osc rq delete" doing something complete different would create some problems. In most cases the osc is telling the user how it should be used now. The case where I have no idea how to do this is the sr creation. At least not without having a disadvantage for all future in the interface. Just a list of all incompatible changes done this time so far, they were done within the last month by multiple contributors trying to improve the interface: osc submitreq create -> osc submitreq osc submitreq accept/decline/show/revoke -> osc request accept/... osc submitreq delete -> osc request wipe osc deletepac -> osc delete or osc rdelete osc deleteprj -> osc rdelete osc rlog -> osc log osc rprjresults -> osc prjresults osc rresults -> osc results osc req -> osc api
There is always a learning curve when people start to do things and I think we agree that we want more people to use the buildservice and it's tools like osc. Changing some of the most common commands (and I think the submitreq is part of that set) will push many people back to the start of that curve.
By abandoning interfaces now, the user will get the impression: "this worked yesterday but does not any longer, something is broken ...". After all we should not forget that for most users of the buildservice, the buildservice itself is just a method to get work done (change code, look at diffs, submit changes,...) and they don't really want to care about the technology or cleanlyness of a commandline interface.
Yes, it is not nice to force people to relearn again (and I agreed to that already in the original mail). It is just the lack of ideas how to avoid a permanent drawback for the entire future. It would be of course better if everything would be right from the beginning, but you know that one sometimes need a version 2...
There are vaild reasons and technical neccessities to add and extend the interface, but up to now I don't see the reason to break things.
just my 2 cents since you asked for comments ... ;)
thanks ! adrian
(1) thinking about it: would it be possible to hack up some statistic in the api to see which commands/variants are used frequently to get an idea when some possibly outdated interface is really "almost" not used anymore ?
-- 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 Friday 05 June 2009 06:07:10 Adrian Schröter wrote:
Just a list of all incompatible changes done this time so far, they were done within the last month by multiple contributors trying to improve the interface:
osc submitreq create -> osc submitreq osc submitreq accept/decline/show/revoke -> osc request accept/... osc submitreq delete -> osc request wipe
okay, so all "osc submitreq foo" are mapped to "osc submitreq foo" or "osc submitreq foo2". What is so different about "create" that it should have it's own command ? What about just "osc request submit" (or "submitpac" or something in that direction) and leave the "submitreq" namespace alone ?
osc deletepac -> osc delete or osc rdelete osc deleteprj -> osc rdelete osc rlog -> osc log osc rprjresults -> osc prjresults osc rresults -> osc results osc req -> osc api
-- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux MacBookRudi 2.6.30-rc6-git3-4-default #1 SMP 2009-05-25 14:11:59 +0200 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Freitag, 5. Juni 2009 10:34:27 schrieb Ruediger Oertel:
On Friday 05 June 2009 06:07:10 Adrian Schröter wrote:
Just a list of all incompatible changes done this time so far, they were done within the last month by multiple contributors trying to improve the interface:
osc submitreq create -> osc submitreq osc submitreq accept/decline/show/revoke -> osc request accept/... osc submitreq delete -> osc request wipe
okay, so all "osc submitreq foo" are mapped to "osc submitreq foo" or "osc submitreq foo2".
What is so different about "create" that it should have it's own command ?
What about just "osc request submit"
that was my first implementation, but some people of our discussion round disliked this for these reasons: * It is basically "osc request <type>", this is conflicting already in the delete case and will most likely conflict again in the future when introducing new types. * It is clear that all "osc rq" commands are the same for all kind of requests, while all "osc <type>request" are special for each type. * "osc sr" is much shorter and handy ;) and at the same level as "osc ci" for example.
(or "submitpac" or something in that direction) and leave the "submitreq" namespace alone ?
submitpac would be thinkable (or submitpkg ?, we do just consolidate this to one writing). But how would the other requests be written ? How can you see at the command that it is a request and not a real action ? The current implementation has for that reason always the "request" as part of the command.
osc deletepac -> osc delete or osc rdelete osc deleteprj -> osc rdelete osc rlog -> osc log osc rprjresults -> osc prjresults osc rresults -> osc results osc req -> osc api
-- 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
Hello, On Jun 4 19:01 Adrian Schröter wrote (shortened):
Are there really that many people who use osc via scripts ? Having a usable interface is IMHO more important in the long run.
A consistent user interface is much more important. It will avoid zillions of problems and bugs in the future when zillions of average users use it wrong by accident just because they do not easily understand how to use it. The current osc commands look very much like a stockpile of quickly hacked stuff - I assume it actually is a stockpile of quickly hacked stuff ;-) Now - only now - before zillions of users use it - is the right time to really get rid of the mess - no continuously maintaining a backward compatible "mess-mode" - just get totally rid of the mess now! Waiting any day longer gets more and more users somehow familiar to use the mess until those "old users" are the majority and then you can never again get totally rid of the old mess. Therefore: Get rid of the mess now! The sooner the better! Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
On 2009-06-05 10:00:54 +0200, Johannes Meixner wrote:
On Jun 4 19:01 Adrian Schröter wrote (shortened):
Are there really that many people who use osc via scripts ? Having a usable interface is IMHO more important in the long run.
A consistent user interface is much more important.
It will avoid zillions of problems and bugs in the future when zillions of average users use it wrong by accident just because they do not easily understand how to use it.
The current osc commands look very much like a stockpile of quickly hacked stuff - I assume it actually is a stockpile of quickly hacked stuff ;-)
Hmm about which commands are you talking or what do want to change (or are you referring with "osc commands" to the new "request command proposal")? Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Jun 04, 09 16:40:40 +0200, Marcus Rueckert wrote:
Show existing requests: =======================
osc list # list requests (maybe we can make this one obsolete)
"osc request list" if at all.
Typo. 'osc request list' was meant.
osc list is too unspecific and could confused as synonym for "osc ls".
'osc list' and 'osc ls' are already synonyms. 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: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (7)
-
Adrian Schröter -
Boyd Lynn Gerber -
Johannes Meixner -
Juergen Weigert -
Marcus Hüwe -
Marcus Rueckert -
Ruediger Oertel