And another few comments about split packages vs. small/slow arches:
1. Most of your arguments show that you actually never really tested all of KDE. Which I can understand. But that menas that you actually just threw a stable tag on all KDE apps while you maybe tested only 75%. That won't change with split ebuilds, but now the untested parts of KDE are *officially* untested what they probably always were.
Huh?? You are very mistaken. We don't keyword anything we don't test. It has to compile and run before we add ~mips. Granted, we typically try to follow x86 for stable marking, since we don't really have enough users to make a significant testing period on our arch alone meaningful. However, most bugs here are either arch neutral, or they have to do with our toolchain and nothing to do with kde, so we can do this.
2. Splitting KDE puts you in the same boat as GNOME. So KDE should handled the same way GNOME is (whichever way that is).
The difference is, gnome isn't distributed as monolithic packages by upstream. Also, kde is c++, which takes far longer to build than c, which is what gnome is written in. However, you bring up a good point...I've always hated how disconnected gnome is in this manner, which is one reason I've always preferred kde.
3. If decompressing and compiling^Wconfiguring is really that slow on other arches, maybe the KDE maintainer could put still keep some monolithic ebuilds (maybe package.mask'ed) in the tree for your testing pleasure. That shouldn't be much work for them but won't make (1) go away either.
That's all I *really* want, is for the monolithic ebuilds to stick around for those that want them.
4. If you really can't test all of KDE then I'd say don't mark stable on MIPS etc. which isn't tested. That means that for those small arches probably only 25% (or even only the core apps) will be officially stable. But this is (a) probably what they are used to from Gentoo anyway and (b) what was the true state but inofficial state of the KDE packages anyway.
See my response to 1.
Steve
-- [email protected] mailing list
