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:
Hi,
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?
Klaas
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 have. 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?) Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development