Mailinglist Archive: opensuse-buildservice (213 mails)

< Previous Next >
Re: [opensuse-packaging] Re: [opensuse-buildservice] Important osc version 0.119 release !
  • From: Michael E Brown <Michael_E_Brown@xxxxxxxx>
  • Date: Tue, 16 Jun 2009 11:10:03 -0500
  • Message-id: <20090616161002.GA18152@xxxxxxxxxxxxxxxxxxxxxxxxx>
On Tue, Jun 16, 2009 at 05:27:18PM +0200, Vincent Untz wrote:
Le mardi 16 juin 2009, à 17:07 +0200, Adrian Schröter a écrit :
Am Dienstag, 16. Juni 2009 16:44:05 schrieb Vincent Untz:
Command UI changes

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
osc rebuildpac -> osc rebuild

Hrm. I didn't see the thread about this, but I would have also mentioned
that breaking the UI for this isn't really a good thing. Sure, it'll be
necessary at some point, but I don't agree it was necessary for those
new features. Some complete redesign would probably have been better,
since we're probably keeping some bad UI.

- renaming rebuildpac but not copypac or linkpac is a bit weird.
- remotebuildlog while we have rdelete, rdiff, etc. (sure, rbuildlog
is an alias, but then why keep remotebuildlog?)
- we have results, but buildlog, buildinfo, buildconfig, etc.? I would
have expected buildresults

(so my main issue is that we're breaking the UI now, and we'll probably
have to break it again later)

We think that these changes avoid exactly that we need to break request
handling commands again. But keeping the old ones would create conflicts
and again.

I'd disagree about not needing to change the request handling commands
anymore. At least, I disagree if we want to have a good UI.

First thing that strikes me is that submitrequest is not a good name
anymore. I mean: deleterequest and changedevelrequest are pretty clear,
since they are about "delete" and "change devel". But submitrequest is
about "submit"? What does that mean?

Also, when I do deletereq, I submit a delete request. So it could have
lived as a subcommand of submitreq (assuming the
accept/decline/revoke/delete subcommands were moved, which is the case
since the moved to the request command).

IMHO, we can't really make the UI good if we don't look at the big
picture. And the bigger issue about the osc UI is that osc does multiple

+ commands to work on a local checkout (co, commit, add, rm, build,
+ commands to work on the project structure of obs (meta, copypac,
linkpac, etc.)
+ commands for the collaboration features (branch, sr, req, etc.)
+ some misc commands to interact with the build service (maintainer,
platforms, search)
+ (maybe some other categories)

I'd like to add my 2c here:

We also have the same set of commands to work on:
-- local checked out copy of a package/project
-- remote versions of packages/projects

And there are vast inconsistencies in the handling of the differences
between the two. This is pretty frustrating to develop around. Some
commands are only available on a local checked-out copy of a project
when it seems like they should work remotely just as well.

Some examples:
results / rresults
but: results_meta has no remote equivalent

buildinfo: no remote

Personally, what I would like to see would be something like:
osc --local results ...
osc --remote --project XXX --package YYY results ...

or something similar so that both remote and local commands all have the
same command line structure and a defined way to run them remotely. Of
course, there are going to be some commands that dont make sense
remotely, like 'osc resolved', for example.


< Previous Next >
Follow Ups