One of the things that lately became more and more important for Gentoo, IMHO, is the lack of an x86 team. As the time goes by, amd64 desktops are getting more and more used, and this is good, IMHO, because a lot of software bad coded is not working there, removing a lot of cruft from the packages base users are going to have (am I referring to Helix Player? well not exactly but that’s one of them).
Unfortunately one of the things that this is making clear is that we need an x86 team as many devs (like me) are getting access only to amd64 hardware so can’t test and mark for x86 systems.
Also if this can seem a problem not exactly extended, at the time of writing I have marked stable a couple of packages (xine-lib and libtorrent/rtorrent) which aren’t stable on x86.. instead of an amd64-imlate.txt file (which shows which packages are stable on x86 but not on amd64) this time we need an x86-imlate.txt.
It can seem a little problem but consider that, just myself, I’m maintaining 13 packages, and I’m on media-video, sound and pam herds (and also az who’s the other main pam developer uses amd64 as main arch). This means that 13 + eventual packages that I mark stable on media-video, sound and pam are going to be marked amd64 before x86.
Add to that the other devs in my same situation and we’re going to have more than a few packages maintained on just amd64.
There is an x86@g.o arch alias. Sure, there aren’t many people on it, but I think they’re still enough to mark a few packages stable.
This may be a stupid idea so feel free to shot me if it is but isn’t amd64 effectively x86+64stuff can you not do x86 testing in a x86 32bit chroot?
Sometimes in chroot things work/doesn’t work while they don’t/do on a real machine.I’d rather use a real machine for testing.
Lost cause… I’ve been pushing for this for the better part of two years. It’ll be blocked by the shoddy QA crowd who want to be allowed to carry on breaking everything they touch.