Am Donnerstag, 28. November 2013, 14:49:32 schrieb Stephan Kulow: ...
We basically want to put the pressure on the submitting packager not the user. Using factory should be safe, for this we want to revive a thing that has been lost on the way: Bernhard's factory-tested project.
While I would re-phrase this, I 100% support this. I think we always wanted to have a always usable factory and in total this helps all packagers. The devel projects are still a good idea, but I agree 100% that it is not enough to validate a new submission. Great that you picked up the make-factory-always-usable approach :) My hope is that we can developer some kind of objective QA measurements in future for this. Eg. X server is not only compiling, but even starting :) Or bluez update does not break the tools for one of the desktops like it is even the case for openSUSE:13.1 released version.
And we want to open another submission path: from staging projects. Consider a situation where recent updates to GNOME and automake 'clash', causing problems when they're installed together. Right now we throw both into Factory, breaking both for our Factory users until we solve the issues. Instead, we think working on these issues in a separate 'staging project' could be the solution. None of us knows how *exactly* it will look alike because we need to get a conversation with the OBS team going. But the basic idea is:
- GNOME:Factory stays the devel project of things that relate to GNOME updates - devel:tools stays the devel project of things that relate to automake updates - on automake updates, we open up a new devel project that stages GNOME packages for the new automake. In there, GNOME devs and automake experts work together to fix them and updates in there are submitted either back to GNOME:Factory and are integrated right into Factory. Or if that's not possible, the automake update is "grouped" with various GNOME package updates and these updates end in Factory together.
There are several problems with the current "everything through devel project" approach we need to solve.
I just want to point out that this is a process limitation of Factory. The OBS source link system was actually designed that you could submit it from any project and the devel project would get it as well. With current .changes files it will most likely get into broken state for manually merging. This could be improved though, but it is not a big problem if this happens anyway. Or, alternative solution, you just put source links pointing to the devel projects into the staging projects. Afterwards developers needs fix source in their devel project, but monitor results in the staging project as well. Submission can be created then from either the devel projects or from the staging project. It will not lead to merge problems with this setup. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org