On 11/28/2013 07:49 AM, Stephan Kulow wrote:
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
One thing I tried was to setup "rings" to help easing the very painful
staging projects (with 6800 packages, every staging project as we use
them is a monster). That experiment has shown rings to be worthy way
to check, but they won't work as I thought with the OBS as it is. We
need to think bigger. So we tried to come up with an idea on how to
improve the factory development process that includes a more clever way
to utilize staging projects and openQA.
As this development process is a bit hard to explain in email, Alberto
and Ancor prepared an interactive diagram:
Let me add a few observations that may give you a place to look to draw ideas
from. Essentially trying to keep factory working at all times presents the
classic rolling-release model challenge. "How to make the big changes, but keep
a working factory distribution at the same time while minimizing the
configuration and setup change impact to users." The big changes like systemd,
boot loader, gcc, LSB migration, etc..
If you view factory from a rolling-release standpoint, modeling staging around
the lessons others have learned providing a rolling-release may simplify what
you are trying to accomplish here. Yes, you have release-targets that will
become openSuSE number next, but factory continues to roll on and should remain
a usable and functional group of packages throughout the development cycle.
One distro that has done a very good job at making the rolling release work is
Archlinux. In implementing their rolling release they employ two basic
collections of packages. The use a "testing" repository where packages
incorporate the latest stable source from all vendors and then ultimately move
to "core" and become the Archlinux packages. Their "testing" is
you envision as "staging" and "core" is what you have as factory.
The biggest difference in their approach is they have a more distributed spoke
and wheel type of package maintainer setup with individual package managers
responsible for large logical groups of packages that work their way through
"testing" into "core". This lets them identify those sets of packages
present the biggest challenge and impact to move through "testing" to
Just as you envision "groups" of packages remaining in "staging" until
move to factory.
I can't give a dissertation on the exact assignment of packages to package
managers distribution, etc, but what I can tell you is that they do (and have
done well for a while) exactly what you are discussing doing for factory. Rather
than reinventing the wheel, it may be well worth the while to see if there are
things that can be learned there that can save some trial and error here and
reduce both the number of times factory gets "broken" and the
configuration/setup jolts to factory user.
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.
We have more ideas, but we can only achieve that if we get help, so let
me finish with another favourite of mine
What would you think if I sang out of tune?
Would you stand up and walk out on me?
Lend me your ears and I'll sing you a song
And I'll try not to sing out of key
Oh, I get by with a little help from my friends
David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org