Mailinglist Archive: opensuse-factory (482 mails)

< Previous Next >
[opensuse-factory] One of the options for staging projects

we are having a nice torrent of ideas in this mailing list since coolo
presented this proposal last Thursday:

Some of them are related to staging projects, so I will try to expand
further one of the options regarding what could be happening inside that
dashed box in the diagram.

The main goal of staging projects is preventing Factory from breaking
so often by creating a "temporary and alternative Factory" where
dangerous and conflicting submissions have to learn to live in peace
and harmony before entering the real Factory. The original mail from
coolo contains a great example with new automake.

So let's look closer into all those boxes, arrows and decision boxes:

1) Developer sends SR#1 to Factory and review team decides it needs
staging, so staging project gets created (let's assume the decision is
made by the review team, even if this is currently being discussed in
the mailing list). The staging project initially contains only the
package that is being sent and rebuilds everything from Factory that
depend on it.

2) Stuff gets broken in staging, the submitter that sent SR#1 is now
responsible for the project and in order to get SR#1 in Factory has to
make sure staging project gets fixed.
2.1) The submitter fixes easy things that got broken.
2.2) The submitter coordinates with people who maintain packages that
got broken. That means several people working on several packages
(very often from different devel projects) all together to fix the
new staging project. The fixes can be done in the devel projects or
directly in the staging project.
2.2.a) Fixes in the devel projects gets into the staging project just
by sending a SR to factory, more details below.
2.2.b) Every time a fix is done directly in the staging project it has to
be sent back to the corresponding devel project.

3) When everything is fixed, stuff is merged in Factory and the staging
project is deleted. See details below.

Let's elaborate a little bit how 2.2.a works:
- From one of the involved devel projects, SR#2 is sent to Factory fixing
issues in staging project.
- SR#2 gets grouped with SR#1 and the corresponding package in the
staging project is replaced with link to the version in SR#2. New
submissions replace the old ones.

According to the procedure explained above, this is how 3 works:
- When everything is fixed, there are in fact no local changes in the
staging project except for things corresponding to the state of SRs in
- Group will get accepted (all SR at the same time) and staging project
deleted (as it is now merged into Factory).

A last remark about the whole process:
- if a package is involved in a staging project, submit requests to Factory
that doesn't contain fix for the staging project are declined. It might be
few exceptions like really dangerous zero day security exploit or data eating
monster, but certainly not ordinary version bumps.

This is just a proposal on how staging projects could work. The main
goal of this proposal is to partially move the responsibility of the
integration process into the community of packagers so:
- Staging project maintainer has to cooperate with package maintainer
to get his SR in.
- Package maintainers have motivation to fix their stuff, otherwise
new versions don't get included.

The main advantages if this approach are:
- Everything has to go through package maintainer to make sure
changes don't get lost, package maintainers knows about the problems
and agrees with the solution
- We move from one good state to another, accepting only changes
together with fixes.

What do you think? What do you like/dislike? Opinions?

openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at] Czech Republic
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >