Mailinglist Archive: opensuse-factory (1134 mails)

< Previous Next >
Re: [opensuse-factory] Calling for a new openSUSE development model
  • From: Jos Poortvliet <jos@xxxxxxxxxxxx>
  • Date: Tue, 19 Jun 2012 22:33:18 +0200
  • Message-id: <2610849.mN2XSNLY3u@linux-6upc>
On Friday 15 June 2012 09:31:19 Bernhard M. Wiedemann wrote:
Hash: SHA1

Am 14.06.2012 10:46, schrieb Stephan Kulow:

It's time we realize delaying milestones is not a solution.
Instead, let's use the delay of 12.2 as a reason to challenge our
current development model and look at new ways. Rather than
continue to delay milestones, let's re-think how we work.

openSUSE has grown. We have many interdependent packages in
Factory. The problems are usually not in the packages touched, so
the package updates work. What's often missing though is the work
to fix the other packages that rely on the updated package. We need
to do a better job making sure bugs caused by updates of "random
packages" generate a working system. Very fortunately we have an
increasing number of contributors that update versions or fix bugs
in packages, but lately, the end result has been getting worse, not
better. And IMO it's because we can’t keep up in the current

I don't remember a time during 12.2 development when we had less
than 100 "red" packages in Factory. And we have packages that fail
for almost five months without anyone picking up a fix. Or packages
that have unsubmitted changes in their devel project for six months
without anyone caring to submit it (even ignoring newly introduced
reminder mails).

So I would like to throw in some ideas to discuss (and you are
welcome to throw in yours as well - but please try to limit
yourself to things you have knowledge about - pretty please):

1. We need to have more people that do the integration work - this
partly means fixing build failures and partly debugging and fixing
bugs that have unknown origin. Those will get maintainer power of
all of factory devel projects, so they can actually work on
packages that current maintainers are unable to. 2. We should work
way more in pure staging projects and less in develop projects.
Having apache in Apache and apache modules in Apache:Modules and
ruby and rubygems in different projects may have appeared like a
clever plan when set up, but it's a nightmare when it comes to
factory development - an apache or ruby update are a pure game of
luck. The same of course applies to all libraries - they never can
have all their dependencies in one project. But this needs some
kind of tooling support - but I'm willing to invest there, so we
can more easily pick "green stacks". My goal (a pretty radical
change to now) is a no-tolerance strategy about packages breaking
other packages.

How about defining a stable core (should include at least ~200MB JeOS
packages (kernel,bash,zypper,...)) and we run automated tests (e.g. on
openQA.o.o) on a Staging area before making it the new stable core.
If something unexpected breaks, we revert the change, extend the tests
to catch the breakage and fix the breakage in Staging.

I like this idea as it would make testing an integral part of how we work.
Nobody has an opinion about this?

We could do the same (with possibly less strict rules) with an
extended core that includes packages that are important for many, like
X11 and firefox but not necessarily KDE or GNOME, because
a) they are huge and
b) you always have alternatives if they break.

It could, in turn, even become our distribution. We'd just release that
core, then OBS etc provides the rest via either devel projects, or
Tumbleweed, or both. Then at release time we release slightly tested
snapshots of Tumbleweed on top of the latest core.

We could even quite easy to more regular releases (tied to the Linux Kernel,
maybe? 3-4 months?) and 'sub projects' like KDE, GNOME or other devel teams
could do releases on their own, with a set of packages the put on a stable
core and put into a ISO image.

For this to work, it would be important that OBS supported
submitrequests for groups of packages. This will also be useful, if
you have a new version of A that requires a new B, but having the new
B would break the old A.
Having group-submits would allow to have consistent versions stay

Then we could go as far as creating a temp project for every
submitrequestgroup to Core, that also builds depending packages (like
with OBS' linkedbuild function) and running automated tests on it as
part of the review process (best including an rebuilt
installation-image too).
This way a submitter could notice, if his change broke something and
either fix his package or (let) fix the other package and submit both
together to pass the tests.

Bernhard M.
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

< Previous Next >
This Thread