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.