Le lundi 25 juin 2012, à 14:40 +0200, Jan Engelhardt a écrit :
On Monday 2012-06-25 10:18, Frederic Crozat wrote:
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
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
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.
Les gens heureux ne sont pas pressés.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org