Le lundi 25 juin 2012, à 14:40 +0200, Jan Engelhardt a écrit :
On Monday 2012-06-25 10:18, Frederic Crozat wrote:
I don't mind obvious one-liners, but Base:System/kmod was updated without making an SR. That way I had no knowing nobody prepared a new one and had made myself the work to update it to version 9, only to get a "you must run osc up first" with naturally sufficiently conflicts when attempting to check in. That sucks.
Another solution would be to more broadly use osc collab to work on packages, to prevent stepping on other people toes and duplicate work.
The collab syntax is currently rather random.
No, it's not random. It might not be completely consistent with the core osc one, though.
Sometimes you have to add option dashes, sometimes you don't. Compare:
osc help osc collab --help
Is this an example? If yes, try "osc ls help" :-)
osc someaction security:netfilter iptables osc collab someaction --project=security:netfilter iptables
Yes. This is purely historical, back when the collab plugin was only working for one project. But it's also for convenience reasons, as you can define your favorite projects and then you can simply do: osc collab someaction gnome-shell Which is what most users of collab do.
osc collab buildsubmit -m "my message" osc collab comentset pkg "my message"
That's because in commentset, "my message" is a first-class argument (by that, I mean: it's what the command is about, setting a comment). While for buildsubmit, "my message" is just a marginally useful commit message. That being said, I'm happy to fix usability issues people have with collab. So far, people had no issue with the UI/syntax, so we kept things they are. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org