Sascha Peilicke - 10:17 3.12.13 wrote:
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:
- 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 :-)
And probably rightfully. Although I would say that bugfix releases not changing API/ABI probably don't need to go to such an extent.
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.
Well, apart from staging projects, there is need QA part in the proposed workflow ;-)
Though this is a counter-example, I like the general idea.
Glad to hear so.
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.
Well, I would make it a little softer as part of the review - if you see that there is just typo in man fixed, no need for staging, if all headers got renamed, we need staging for sure. These to being just extremes, but what I'm saying is that I would like to make it more fuzzy...
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.
Sure, packages should be able to ask for it as they should know much better how drastic are the changes.
- [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.
Actually both. It was meant that the guy maintaining staging project has to work together with other people to get rid of his staging project and get stuff in, but it works also other way around. Packager need to cooperate with staging project maintainer to get his new and cool version in.
- 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
Well, it works other way around as well, why should glibc maintainer fix something that uses API that was deprecated long time ago. The important part is that they should work it out together, otherwise neither of them can in.
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 :-)
Well, this should solve the failing packages in Factory and make Factory buildable/rebuildable all the time. To make it stable and working, we need QA, that was in another box :-D -- 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