On Thu, 28 Nov 2013, Michal Hrusecky wrote:
Richard Biener - 15:45 28.11.13 wrote:
On Thu, 28 Nov 2013, Stephan Kulow wrote:
Hi
It's Thanksgiving today and we had a great harvest - "Bottle" rocks. But today is also a good time to plant new seeds for even better openSUSE releases. Factory has a healthy growth, but we have to make sure it's growing in the right direction and so the openSUSE team at SUSE had an on-and-off discussion basically since 12.3 on how to improve things.
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
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
In that song Sheryl Crow sings "It's just a question of eliminating obstacles", so what did we in the openSUSE Team do to help? We focused on getting a grip on testing by improving openqa (http://s.kulow.org/openqa-blog), but we soon found out that it was not good enough to test Factory ISOs. Factory is broken often enough not to produce ISOs at all, ISOs can't be installed and once these problems are sorted out, we found in openqa very basic things to be broken, but it was too late to protect factory users to run into them.
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
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.
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:
- 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.
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
Back in the old times some people inside SUSE thought of following the Debian testing way. The road block then was the inability to track bugs filed against a package. To recap how Debian testing works - a package update gets pushed to "unstable", then, if no bugs against it appear for $X time, it gets automatically pushed to "testing" (if all dependencies it has at this point can be satisfied there - mind that Debian has a lot more versioned dependencies). We still don't have a "package" field in bugzilla, so copying this scheme 1:1 doesn't work.
But we don't have to re-invent the wheel, no?
The closest thing to Debian testing we have is openSUSE Tumbleweed though it's a very manual process there.
But isn't the proposal to have a Tumbleweed for Factory?
Don't really get the last question, but let me share my opinions. Tumbleweed is great, but it is a workaround for not stable enough Factory. If Factory would have been stable enough for everyday use (with only few minor hiccups), we wouldn't have needed Tumbleweed IMHO.
IMHO we would have "auto"-Factory which simply aggregates from all devel projects for example and "Factory" which is a Tumbleweed of that. But wait ... it already works that way. I don't think there will be a good solution without "splitting" Factory. What you then call Factory is up to you. With the "Tumbleweed for Factory" I was simply proposing that in additional to Factory as we have it today we have the "stable" Factory that is operated in "Tumbleweed" mode - pick up changes from Factory in a more controlled manner (aka when they work). Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org