[CentOS] Blog article about the state of CentOS

Greg Bailey

gbailey at lxpro.com
Wed Jun 17 18:21:00 UTC 2020


On 6/17/20 10:38 AM, Michael Kofler wrote:
> Hi,
>
> I am the author of said blog article.
>
> FIRST: It was never my intention to criticize the CentOS
> team. I appreciate the hard work you are doing. If my blog
> text (which is in German langugage) gave a wrong impression,
> I apologize.
>
> SECOND: I LOVE CentOS. Otherwise it would not matter to
> me. I use CentOS to teach Linux administration at
> university, I promote CentOS in my books and I use it
> personally on some servers.
>
> [snip]
>
> I truly believe, Red Hat has the means to make live for the
> CentOS team easier. Either by simply increasing the team,
> the infrastructure to build packages faster, whatever. Or by
> making the clone process easier.

IMHO this is the crux of the problem.  I feel for the CentOS team every 
time they get beat up by users asking why things take so long, and 
they're forced to explain over and over again how they have to 
re-engineer processes that the RHEL team has already engineered.

In theory, both RHEL and CentOS start from the same sources -- 
git.centos.org -- which is a great thing.  But, RHEL obviously has 
package build infrastructure, release composition, release management, 
and QA (among other) systems that are requisite steps to building and 
releasing, say, RHEL 8.2.  It makes me sad that the CentOS devs (most of 
whom are Red Hat employees, as I understand it) are forced to 
re-implement what the RHEL team has already implemented, without any 
advice, guidance, or tooling from the RHEL engineering team.  (i.e. the 
CentOS team has to discover that "these packages have to be built in 
this order, or with this modified build environment", etc. on their own)

It's not clear why 2 different groups at the same company doing the same 
thing can't combine resources.  Why can't one group at Red Hat produce 
binary RPMs from git.centos.org that find their way into both a RHEL 
compose and a CentOS compose?  And would the composes then be so 
different if the only thing that varied was the package set and branding?

Perhaps the duplication of engineering effort stems from the history of 
CentOS being a separate organization that's still undergoing integration 
with other Red Hat teams.  And I'd love to be enlightened if any or all 
of my assumptions above are wrong; my perspective is just that of a 
long-time Red Hat Linux, RHEL, Fedora, and CentOS user (since 1998 or so).

-Greg



More information about the CentOS mailing list