On Monday 02 December 2013 19:52:47 Michal Hrusecky wrote:
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.
The art here is how to make that decisions. If it would be based on past experience, we would always recommend to stage glibc :-) On the other hand, there's udev, which doesn't break builds but peoples running systems. So staging udev wouldn't reveal anything until people actually test the staged udev. Though this is a counter-example, I like the general idea. The Factory maintainers and the review team could come up with a list of packages that are likely to cause issues. For those we could just demand staging, no matter what. We would publish / version the list somewhere and just add a check to factory-auto. Another category would be packages where the submitter demands staging. I expect this to happen far less frequently but we should emphasize that this option is available. Responsible submitters may want to use it if they bring major changes to the distro.
2) [snip]
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.
To whom does the SR belong here? Is it the staging prj maintainer that wants it or the packager? IMO its usually the latter wanting the SR to get in while the former wants to get rid of the staging project again.
- Package maintainers have motivation to fix their stuff, otherwise new versions don't get included. I think this was discussed elsewhere already, but not-so-core community members are often asking why they should fix their package if breakage came from elsewhere (e.g. new glibc vs. random game pkg). But it's
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.
I think you are correct that we have to bring the packagers into the fix-it boat. But let's not be overambitious, this won't solve everything :-)
What do you think? What do you like/dislike? Opinions?
-- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)