The "progress?" thread carries questions, explanations and arguments,
a healthy portion of mud and a bit of fud for spice, but not much is
coming out of it, apart from the volume of the conversation itself.
So I'll make an attempt at being constructive. If I end up demonstrating
my complete ignorance of the build system while also offending people
at the same time, just take a moment to bash me and at least enjoy that.
There are essentially two crowds here, the one bigger, the other more
indispensable: the "we are tired of waiting, WTF is holding up our
distros?" crowd and the "we are working our asses off for you and we're
sick of your complaining" crowd. Both are right in their own minds, but
both have also fully valid arguments, objectively speaking. No solution
will work, unless it somewhat meets the needs of both crowds.
The most repeated argument from the impatient is that of security
updates. The most repeated argument from the patient is that of binary
compatibility and the hassles of achieving it.
Now I wonder, what's the difference between the 5.5 and the 5.6 build
root? I don't know, but I am assuming there is none, because any random
package in 5.5 must be upgradable to 5.6 without pulling in an entire
distro as a dependency. Hence, it should be possible to build security
updates from 5.6 in the 5.5 root and they would be compatible with both
5.5 and 5.6.
So then, assuming that that is true, why can't security updates from
5.6 be compiled in the existing 5.5 root together with any specific
dependencies they might have, and be released in the 5.5 tree? Doing so
would put the CentOS and RH repos out of sync, but would still preserve
binary compatibilty. And repo sync has never been a CentOS goal anyway.
In other words, we would get package-1.2.3-1.x86_64.el56.rpm in 5.5 and
later that very same package would appear in 5.6 as well. yum has no
problem with that. The impatient crowd gets security updates. The patient
crowd can then take its time to create a quality 5.6 distro. Nobody gets
hurt in the process.
And there's another similar compromise between speed and perfection,
which I suggested already earlier: just release the repo first, as soon
as it's ready, and only then start working on the installer ISOs. Then
those who already have 5.5 installed and want to upgrade, can just do so.
Anyone who wants a fresh 5.6 in a hurry, can install 5.5 and then upgrade
it. Those who want a comfortable out-of-the-box 5.6 installer, are more
willing to wait. All in all, this way the users can get something faster
without the developers having to make any extra effort, so everybody's
happy, or at least a bit happier than before.
Can somebody please tell me why any of this wouldn't work?
Z
