Stephan Kulow <coolo@suse.de> writes:
Integrating these to make a good distribution is real work. And one of my favourite songs (in that context) goes:
No one said it would be easy But no one said it'd be this hard No one said it would be easy No one thought we'd come this far
:D
https://progress.opensuse.org/workflow/factory-proposal.html
Cool diagram, extremely helpful to convey the idea!
We basically want to put the pressure on the submitting packager not the user.
yay :) !
There are several problems with the current "everything through devel project" approach we need to solve. Our ideas are just ideas, but I had several discussions in various places and nobody offered a better idea. So we really would like to start with it and I would like to hear your concerns so they can be part of the final solution.
This will be a major improvement to what we did so far :) ! There is one thing that I'm missing, but that probably would need other changes on obs than using it differently and adding submit request groups. The build server is what it says: a *build* server. We use it as an integration server, quite successfully, and it comes close, but it is not explicitely targeted at integration. So it is missing a few features to better support integration: * Tools like git support 'merge' tracking of changes in branches back to mainline and from progress in mainline back to the branch. This then also allows to bisect regressions to the integration issue. * Integration means testing, and testing may be a gate/decision point whether further builds make sense at all (think rings). This tracking of test status is not in the tool. And tests should gate further work based on test status. And tests, automatic or manual, have a smart and a stupid order doing them. * There is one thing in which the current proposal will reduce the problem for openSUSE:Factory. Integration means integration into some baseline, to create a new, improved baseline, that should be stable at all times. You want to catch problems early. And for that you contain changes until you are confident they are good for wider release. That's what the current proposal does address. What it will not solve is that you need the very same containment when you target several baselines with the same update, the other thing obs is used for, besides Factory and openSUSE. There, too you want to contain changes until they are 'good enough' to be available for the 'next ring' of things, until you approve them for the whole target baseline. Our current projects simply scope package builds based on what is in the project, not on what is affected in the baseline, let alone what is already tested. You need to 'know' and 'pull in' 'the right packages' to fully cover all dependent packages. And when you use 'links', your project may break because the baseline changes then 'push' into your project. So your project, unless it is accepted as Factory project, will continue to break at random times. What I like with the current proposal is that it is setting a great course for openSUSE Factory, and we need to move towards a more stable factory, a smoother flow. However how will this help dependent multi-target projects (like gnome, or kde or databases or d:lang:*) to likewise be stable at all^wmost times? It looks to me like the flow that is proposed here continues to break projects that build for both factory and other released distributions. S. -- Susanne Oberhauser SUSE LINUX Products GmbH +49-911-74053-574 Maxfeldstraße 5 Processes and Infrastructure 90409 Nürnberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org