Mailinglist Archive: opensuse-factory (1029 mails)

< Previous Next >
Re: [opensuse-factory] O Factory - Where art Thou?
On Thu, 28 Nov 2013, Michal Hrusecky wrote:

Richard Biener - 15:45 28.11.13 wrote:
On Thu, 28 Nov 2013, Stephan Kulow wrote:


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

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
(, 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:

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
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 Biener <rguenther@xxxxxxx>
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >