[Dev] Enhancing development workflow

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Wed Oct 29 10:42:05 GMT 2014


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


More information about the Dev mailing list