On Friday 15 June 2012 09:31:19 Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 14.06.2012 10:46, schrieb Stephan Kulow:
Hi,
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 model.
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 together.
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.
Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/a5McACgkQSTYLOx37oWRjcwCg0F1/osxuDVD0kBazP8z1lb3m hY8AoOLlddAcPxe+r4+zwS+CsPmpGrQ9 =yp9n -----END PGP SIGNATURE-----