-----BEGIN PGP SIGNED MESSAGE-----
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
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
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.
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.
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org