On 11/28/2013 07:49 AM, Stephan Kulow wrote: <snip>
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
<snip>
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:
https://progress.opensuse.org/workflow/factory-proposal.html
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 essentially what 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 that present the biggest challenge and impact to move through "testing" to "core". Just as you envision "groups" of packages remaining in "staging" until they can 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. <snip>
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
Greetings, Stephan
Sheer poetry... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org