Bugzilla – Bug 925613
"osc sr" to submit a group of packages fails if one package is not a link
Last modified: 2015-04-13 06:24:48 UTC
As in many, if not most. deve, projects, there are packages 'not yet' ready to be submitted to Factory or, are simply not meant to go to Factory... so they are not links. Submitting such a devel project using 'osc sr' (wihtout further parameters, that should result in a submit-request group) fails On the example of GNOME:Next osc co GNOME:Next cd GNOME:Next osc sr -m 'Submitting all awesome changes in one go' Submitting package [xxx] [...] Package gnome-battery-bench is not a source link and no target specified. This is currently not supported. submission aborts at this stage. NOTE: it listed all packages to be submitted up to this point (except the ones linking to the same project); despite only a handful of packages actually having changes in GNOME:Next at this moment.
a "osc sr --target-project GNOME" option would solve this, right?
to make my question more clear, this option would overwrite the target project always. So, if there is a package branched from another project it would anyway be send to GNOME in this example. Is that acceptable?
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
okay, so when they are new packages, they could still be links using the missingok feature: osc branch -N GNOME new-package GNOME:NEXT that way you set the target in the package and the submit request (no matter if single or multiple actions) will just work later on. So this problem is already solved? ;)
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.
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. creating the missing link can be done by either: * manually before accepting the request (still empty package, so no conflict with request) * We could introduce a new attribute which could be used that all new packages should be links to project X * 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. any opinions on that?
(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?
I don't mind to offer an option to ignore packages of a request, just I want to add at the same time also an option to define the target. since it might actually be needed ;) yes, esp. the games project is an example where most likely only one or a few packages will be submitted in one step, since the packages are highly independend. But you need to specify these packages then anyway somehow manually. 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.
(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.
Hi Adrian, would you please help to have a look at here? I'm not quite sure whether it is right to assign it to you, please feel free to reassign whenever necessary, thank you!