http://bugzilla.opensuse.org/show_bug.cgi?id=925613 --- Comment #1 from Adrian Schröter --- a "osc sr --target-project GNOME" option would solve this, right? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=925613 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dimstar@opensuse. | |org) | --- Comment #3 from Dominique Leuenberger --- That would work in a lot of projects, but surely not all. e.g. GNOME:Next is linking to multiple devel prjects, as it's there for 'major' updates across the palette. For 'regular' devel projects, one could assume that the parent would be the same for all packages. Except: the ones that are not links might, or might not, have to be submitted. There is no default answer correct -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=925613 --- Comment #5 from Dominique Leuenberger --- Sounds like a very constructed solution, sorry. Maybe look at it practically (let's take a 'normal' devel repo. not GNOME:Next, which can be considered a special case). let's take 'games' (which is a dump of packages, some for Factory, some not) A new package there is generally introduced by means of a submit request from a random home:* to games; it is in many cases NEVER destined for Factory (unless quality and demand are given) osc branch -N in this case: who calls it when? The person submitting the new package has no access; the person accepting the SR will surely not think about it. So in essence: osc sr, submitting a group to a target project, simply can't assume that all packages are links - at very least, it can skip them. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=925613 --- Comment #7 from Dominique Leuenberger --- (In reply to Adrian Schröter from comment #6)

we can add an option to ignore packages without links. On the other hand this contradicts the idea that the entire project gets submitted and you again do not know if some other change actually needs this new package.

The assumption that whole devel projects are submitted together, instead of a subset of packages (maintainers responsibility) is a bit bold, especially on large devel projects... Being able to ignore packages, which are not link, sounds very important to me (and I'm sure other devel maintainers, that actually maintain, and not only dump packages in a project).

creating the missing link can be done by either:

* manually before accepting the request (still empty package, so no conflict with request)

Too error prone. This will be forgotten 98% of the times

* We could introduce a new attribute which could be used that all new packages should be links to project X

This is reasonable for 'mostly devel projects' (like GNOME:Apps, KDE:Extra) and could work in those cases

* we can add this link afterwards. without testing it, "osc linkpac -N ..." should add it without breaking the sources. An interactive option in "osc sr" might make sense as well.

Can be used to fixup indeed, but, as it's a manual step on top of the process, will again lead to issues, to be only done when people are trying to push.

any opinions on that?

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=925613 --- Comment #9 from Dominique Leuenberger --- (In reply to Adrian Schroeter from comment #8)

I take away for now that we want to have the attribute feature as described above and will discuss it within our group before implementing it.

Yes, that sounds reasonable. (besides that, a full workflow still needs to be created for: - Submit a large devel project, e.g. GNOME:Factory (osc sr, all changes one req) - the review team 'somehow' manages to review this. On package 129, there is an error, and the package needs be declined (does that decline the whole group? If so: the whole group has to be resubmitted, resulting in > 100 'new' requests to be reviewed by the team? Or can only the offending package be 'declined' and the group remain 'limbo/inacceptable' until that package is resubmitted and fixed?) Many things can happen here. a package from another devel prj is needed too for example, as it might be found in the <path> structure of my project, but not in openSUSE:Factory in the end... and so on... but different topic, not really 'this' bug. -- You are receiving this mail because: You are on the CC list for the bug.