On 29/10/2014 10:20, Patrick Ohly wrote: > On Tue, 2014-10-28 at 17:05 +0000, Bartosh, Eduard wrote: >>> So you're describing another type of submissions, which should be >> handled by the users themselves: it'd be the same mechanisme as >> sandboxes in gerrit, but for builds. And when you're here, you're not >> far from using home projects in OBS, which is not what we want. >> >> Yeah, it would be good to isolate this types of submissions in another >> namespace (home:devel: or something like that). However, I don't agree >> that prerelease projects can't be used for this purpose right away. >> The only thing which needs to be done is to agree with RE that they >> don't touch submission until devs say it's ok to integrate it. Not a >> big deal from my point of view. > > I disagree about this being not a big deal. This relies on out-of-band, > unrecorded communication between people, which is error-prone. What if > one RE knows not to accept, but some other RE doesn't and accidentally > accepts?
I agree with Patrick. It would be far better if this use case was handled by the workflow. A solution could be to have 'maintainers prereleases', that is isolating the prerelease builds in another location so that RE don't have to take care of them. A special flag on 'gbs sr" should probably be added for that, or alternatively a special target name, same as gerrit: gbs submit-t sandbox/<user>/tizen_common would create a prerelease build over tizen_common, but not visible by Tizen:Common REs. The big problem I see with that idea is: who will take care of the cleanup ? > Tagging different "gbs submit"s with the same tag has a similar problem: > while the developer is in the process of adding submits, the group > submission is incomplete and must not be accepted. If for some reason > the developer gets interrupted, the group submission is left in an > incomplete state and might get accepted accidentally (assuming that it > compiles). Usually, the opposite happens: something is broken because you didn't add the right package in the group submission. Anyway, the case you exposes may happen and should try to handle it too. > Unfortunately I don't have a constructive proposal for fixing this. I have two ideas: 1) simply communicate with REs, because YOU know that there's something wrong. This works reasonably well, and there's nothing to do (except writing a few emails :)) 2) try to enforce the things in the workflow: Submitting multiple packages is a kind of atomic transaction: you want to accept all packages or no package. If not all packages have been added, the transaction is considered as open, and the only permitted operation is to rollback (reject the submission). So we should add an extra gbs operation to 'finalize': when the maintainer 'commits' the submission (which means: 'I won't add any more package to it'), then it could be accepted (if it builds/images are good/tests are ok etc.). If a RE tries to accept a non finalized group submission, (s)he should get an error. Well, that could work, but it's quite difficult to evaluate if your initial problem deserves such added complexity. -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
