Thanks a lot for sharing your thoughts with us.
Quoting Stephan Kulow <coolo(a)suse.de>de>:
But first let me give you some background, that you might not be aware
of: 10.3 had 3334 packages, 11.1 3746, 3605 for 11.2, 3807 for 11.3,
4784 in 12.1, 5710 in 12.2, 6246 in 12.3, 6678 in 13.1, 6800 right now
in Factory. If you need a picture, look at http://s.kulow.org/packages
impressive... And we're talking source packages here, not binary packages.
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.
That looks interesting.. with two, for me, undefined 'dark processes'
with huge impact:
- Needs staging?
- Needs QA?
Are there already ideas on how to implement/formulate this decision tree?
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:
ok, I think THAT partially answers above question with a 'no'
- 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.
In some cases, those breakages are easy identified.. in others, they
are not. Staying with the GNOME examples (where I happen to also have
some good insight): once G:F is being submitted to Factory, it is
known to work on top of what is Factory 'at that moment' There are
very few submits 'auto forwarded' (the team decides that on a
case-by-case.. usually stable dot releases are considered safe to
But as you say, an 'incoming automake' at the same time would of
course 'change' what underlying Factory was, potentially break it
(automake upgrades are known for that and well in our minds).
so, in this case, I'd consider 'automake' to be the critical component
asking for staging.
But what in other cases, where it's less obvious? Like GLIB 2.32 (back
in the days) when the 'include' style was changed to 'force' devs to
do what upstream originally intended: only #include <glib/glib.h>, no
Inside G:Factory this was obviously sorted out prior to submission to
Factory. And I believe we worked well enough in identifying the
problem of this, knowing that other stuff relies heavily on glib,
triggering a staging project (where I myself fixed a bunch of packages
What though, if we'd not have identified this 'subtle' change as
critical? Who would be responsible to 'detect' such things? (ok, let's
not do a RACI for that.. latest with 'A' we will fail to assign this
So far it's in 'trying' to detect those cases early enough, Stephan
does a great job in this, his endless experience is a great asset for
him being able to do so.
Also, we need to be able to define an exit trigger from a staging
project: when do we consider it 'ready'. This does not forcibly mean
100% 'builds' against the offending package (imho), as this could
potentially block a kernel from entering due to some low-hanging fruit
just not having support for that kernel.. critical for the users of
that module, sure, but critical enough to block a kernel update?
(just to show, this is not black/white magic.. and describing this in
a way that it's clear and not 'subject to the mood of Stephan' is
difficult, but should be a goal to strive for).
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org