On 12/17/2020 9:29 AM, Lamar Owen wrote: > On 12/13/20 3:25 PM, Dave Stevens wrote: >> On Sun, 13 Dec 2020 21:05:42 +0100 Rainer Duffner >> <rainer at ultra-secure.de> wrote: >>> It’s also not often the case that you can split this kind of work >>> into a thousand work-packages and have everybody just work 1/2 hour >>> a day on it. >> not like Debian for instance > No, not at all like Debian. Debian doesn't have to try to match the > unattainable goal of 100% binary compatibility with an upstream > source. I've seen a small part of this first-hand, and deducing the > build order to gain binary compatibility is the one thing that can > single-thread the build process quicker than anything else. RHEL > doesn't even have the same need; an RHEL rebuild that didn't have the > goal to be bug-compatible near the 100% level doesn't, either, and can > be built by a lot of people. > > Try it yourself: go back to CentOS 5.5 and attempt to rebuild the > released sources for 5.6 and get a binary compatible build. I've done > it myself for IA64; it was a pain. > > All of the upstream distributions, Debian, Fedora, etc, have a lot of > latitude that CentOS never has enjoyed. Given that rebuilds /had/ been taking longer and longer lengths of time, it was clearly hop(e)xpected that bringing CentOS into the RedHat fold in an official partnership in 2014 would allow for direct access to the RHEL engineers and a path toward making the CentOS Project's rebuilds easier. Indeed, although it's been six years, moving to integrating EL/ELN/CS and RHEL in some way in the pipeline is precisely what had been desired... BUT, defining the problem out of existence while also defining "CentOS Linux" out of existence helps absolutely no one (on the outside, at least). And cutting the support period for 8 in half is so disruptive as to outweigh the progress in other areas. -jc