Am Dienstag, 16. Juni 2009 18:10:03 schrieb Michael E Brown:
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.
Eg: - 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 again 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 things:
+ commands to work on a local checkout (co, commit, add, rm, build, etc.) + 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.
The advantage of that UI would be that it would be easily compatible for all forseable future. But the disadvantage would be that you would need to type way more than now. 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