On Fri, 15 Nov 2013 17:50:33 +0200 Riku Voipio <riku.voipio@iki.fi> wrote: > Wearing my armel buildd maintainer hat, I don't feel the same urgency > as you seem to have - perhaps that's because the armel buildd'd are > less ram-starved than the locos? Yeah, you're spoiled, iirc, one buildd has 3GB of RAM :P > One thing I'd like to avoid is growing the diversity of buildd's we > have. If we have many different buildd hardware, each of buildd > classes needs different kind of maintainence. So when add a new type > of hw for buildd's, it should go in tandem of getting rid of another > type of hw. > > So if we go with nitrogenx 2GB, are we ready to get rid of locos? I can't speak for the rest, but I'd also vote to gradually retire them and send them to interested developers for help in development/porting. I'm also of the same opinion that diversity of buildds should be kept to a minimum. So, in eg. 1 month after deployment of the new systems, retire one loco every week -or all at once, if we're confident the new ones work perfectly. > It's not just DSA, it is also in our porters best interests. We don't > want to end up in the situtation where glibc/udev/systemd/ruby needs > features from a new kernel version, while we are stuck in a old > kernel. You're right, but I think this has only happened a couple of times in the past in the case of armhf that is, but can't remember if we were still using FSL kernel or our packaged ones (not that it matters, just saying). So yes, that's a valid point. Konstantinos
Attachment:
pgpTBLu8Q9UDp.pgp
Description: PGP signature