Hi, we are having a nice torrent of ideas in this mailing list since coolo presented this proposal last Thursday: https://progress.opensuse.org/workflow/factory-proposal.html 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. - 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? -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org