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
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
- devel:tools stays the devel project of things that relate to
- 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.
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org