On Tue, Jun 19, 2012 at 1:33 PM, Jos Poortvliet <jos(a)opensuse.org> wrote:
On Friday 15 June 2012 09:31:19 Bernhard M. Wiedemann
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
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
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
Computational Journalism Server
Data is the new coal - abundant, dirty and difficult to mine.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org