On Tue, Jun 19, 2012 at 1:33 PM, Jos Poortvliet
On Friday 15 June 2012 09:31:19 Bernhard M. Wiedemann wrote:
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?
I like it. If you set the cutoff at 220 MB you can get more than JeOS, I think. On 12.1 a SUSE Studio minimal X with installer builds at about 220 MB. You get IceWM, xterms, and a YaST GUI too, I think. But no browser. With a little shuffling you could probably get the laptop stuff in there and maybe a browser. 220 MB is a mini-CD.
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.
As long as the bigger projects - KDE, GNOME, XFCE, even LXDE have *minimal* customization, I think this works. Upstream or branded is fine, but not something like Unity or the openSUSE GNOME 2 "slab". The desktop projects work hard on their user interfaces and I think they know what they're doing, even if Mark Shuttleworth or Linus Torvalds don't. ;-) Realistically, I think the days of a full KDE or GNOME plus LibreOffice fitting on 700 MB are over. It's really too bad there isn't an open source licensed "cloud" document suite as good as LibreOffice.
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-----
-- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org