Except you cannot do good QA on source-based packages, because there are too many variables involved. You build a binary, test the hell out of it. If it works as it's supposed to, you release it. If not, you patch, rebuild, and test again.
You also don't change software revisions within the stable release unless you absolutely need to -- you backport bugfixes to minimize breakage. If there's a vuln in kernel 2.6.8, you don't move users up to 2.6.11, you fix 2.6.8, and test to make sure the patch doesn't affect other applications.
You need to add SATA cards to your www cluster to add more space. Turns out that driver that is supposed to work in 2.4.20 is barely holding it together. Now you're rolling you're own 2.4.27 package and hoping that 2.4.28 comes out real soon.
You have two web clusters running the same software. You add a third cluster for a new customer. They have a hard requirement for PHP 4.3.9+ with sablotron, xml, and some other nonsense. Trying to do this in the existing OS requires no less than 18 custom packages to be built, most of them supporting libs.
For every example anyone has of wanting to back port changes, not change version, etc I can name two where I'd rather be able to go to the next version easily. I would guess that most admins doing a number of customer driven upgrades find themselves in the same posistion. Either you get really good at building and maintaining mutiple sets of RPMs... and damn does that suck. Or you find an OS that takes care of it for you.
Granted I'm in the ISP space which moves much faster than the short bus of IT known as The Enterprise. But it seems to me you're going to be doing quite a bit of Q&A whether you like it or not. While not as professional sounding, 1-2k users testing a package and bitching if something goes wrong on the forums it is at least as accurate as any real Q&A team I have dealt with.
kashani -- gentoo-user@gentoo.org mailing list
