Stephan,
Thanks a lot for sharing your thoughts with us.
Quoting Stephan Kulow
Hi
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.
https://progress.opensuse.org/workflow/factory-proposal.html
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 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:
ok, I think THAT partially answers above question with a 'no'
- 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.
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
forward)
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