Mailinglist Archive: opensuse-buildservice (351 mails)

< Previous Next >
Re: [opensuse-buildservice] osc submitreq tries to send a submission to the wrong project
  • From: Peter Poeml <poeml@xxxxxxx>
  • Date: Mon, 14 Jul 2008 11:55:02 +0200
  • Message-id: <20080714095502.GY10992@xxxxxxx>
On Mon, Jul 14, 2008 at 10:05:07AM +0200, Klaas Freitag wrote:
Am Montag, 14. Juli 2008 09:39:56 schrieb Peter Poeml:
On Sat, Jul 12, 2008 at 04:35:28PM +0200, Klaas Freitag wrote:
Am Samstag, 12. Juli 2008 01:01:55 schrieb Peter Poeml:

I do not see a reason atm why chaining should not be allowed from a
technical POV as long as we successfully avoid circles. However, the
question is if we get a benefit from really using it - a benefit that is
bigger than the confusion that might arise from that. Not sure atm. What
do others think?


I have the following thoughts about it right now:

This is clearly not how we designed this attribute. It were meant as THE
primary place where development takes place. A place of which, by
definition, there can only be one.
Very valid thought.

Now, I see it can be desirable for users to have a defined path where
changes are moved from A to B to C and then to Factory. For instance,
it might be desirable that changes always first go to foo:KAPUTT first,
then to foo:UNSTABLE, foo:STABLE, then to openSUSE:Factory.
But all foo:* are usually owned by the same people - so the submit
request is somehow useless here (it _is_ of course usefull because of
documentation reasons). Having for example foo:KAPUTT, bar:FORTHEBRAVE
and baz:UNSTABLE before we end up in openSUSE:Factory we have the case.
However, I wonder if thats really a practical case ;)

However, I consider it misuse of the devel project attribute to use it
to define this path (Albeit a good idea ;). This is because it defeats
the purpose of defining the place where changes shall go _first_. That's
what it meant for, and it's actually (more) important to have an
attribute for this, because its (original) purpose is to avoid
submissions to some other place in the path.
Also valid, but what is your conclusion from that?

Oh, I left that part for you ;-)

I think any chaining is project-internal policy and there is no flag
needed for that. Well, I don't know if it's needed, but it can be
handled without, since it is a matter of policy. But what _is_ needed
is a flag to make sure the beginning of the chain is known - which we

I assume it'd be technically possible to chain them, at the expense of
a lot of lookups to be done each time they are used. I'm personally not
if favour of complexity like this.

If finding out where to submit a change to is so complicated, it defeats
the purpuse. If at all, the api should also be able to resolve this
right away, because it'd be quicker, and it's what a user wants to know.
(Or what we thought they wanna know?)

Contact: admin@xxxxxxxxxxxx (a.k.a. ftpadmin@xxxxxxxx)
#opensuse-mirrors on

SUSE LINUX Products GmbH
Research & Development
< Previous Next >