Peter Poeml
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.
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.
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.
So all submissions by default should go right to the root project instead of bubbling up from leaves to branches to the trunk? Maybe the 'Good default' depends on the timing in the development cycle: Submissions always go to the maintainer first, right? During alpha, the maintainer then passes the fix on right into factory. During early betas, they go into the subsystem instead, (so it gets review from the subsystem owner who then submits to factory) and maybe sometimes it even makes sense to have three stages for large subsystems with components, when it late betas approach. I have tried to understand from http://en.opensuse.org/Build_Service/Concepts/Submit_Request how the overall development process shall look like and I wonder where else I should look? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org