Mailinglist Archive: opensuse-buildservice (213 mails)

< Previous Next >
Re: [opensuse-buildservice] new "osc request" handling
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Fri, 5 Jun 2009 06:07:10 +0200
  • Message-id: <200906050607.11162.adrian@xxxxxxx>
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

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

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

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 !

(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@xxxxxxx

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups