[CentOS-devel] CentOS 8/7.7

Lamar Owen

lowen at pari.edu
Wed Sep 18 21:12:41 UTC 2019

On 9/18/19 11:29 AM, Joe Doss wrote:
> ...
> I should have said new contributor, not user. How do I contribute back 
> to the CentOS project? It is pretty clear in this thread we have the 
> developers saying "be patient we are a small team", but I don't see 
> any clear path to offer my time to help like I do with the Fedora 
> project. CentOS 8 is very much in my critical path for success within 
> my organization. I want to use my personal and work time to contribute 
> back. How do I do that?
CentOS is a rather different project than Fedora.  CentOS is a straight, 
debranded, rebuild of RHEL.  The only development in the classical sense 
of the word is for the pieces that aren't straight rebuilds.  The 
'Building 8' page listed the pieces needed; the bulk of the time is in 
the iterative build process and troubleshooting same.  Building out of 
the git.centos.org sources can help; all of the pieces are there except 
for the binary rpms.

> Trust? Deeper things? I fully understand how CentOS is built and why 
> there are things in place to ensure a high quality release. I'm not 
> going to repackage the koji build as a CentOS prerelease and hoodwink 
> anyone.
After re-reading my post I can understand how you get to that statement, 
but that's not what I actually intended.  I was talking about others 
actually building packages for direct distribution to help with the 
build load, not downloading and testing built packages.  My apologies 
for the misstatement.

> I know there are people willing to help with future releases. The 
> CentOS project needs to enable us to do so. Fedora has a beta. RHEL 
> has a beta. Why doesn't CentOS?

Ok, so follow with me for a moment.  CentOS is a straight rebuild of 
RHEL.  This fact is underappreciated, IMHO, and is the foundation for 
everything the project does.  And while I can't and won't speak for the 
developers, I do have some experience in old-school pre-koji  RPM 
packaging and distribution.

So, the RPM NEVRA (Name, Epoch, Version, Release, Arch) tuple for each 
package is a constant and is defined by the upstream package's NEVRA.  
Ok, suppose we have a beta, or two, or ten.  What distinguishes the 
'beta' packages from GA, speaking entirely in terms of NEVRA?  How do 
you update from the 'beta' to GA if package NEVRA doesn't change?  (See 
the Scientific Linux alpha/beta/rc process for reference).

In the specific instance I cited in my previous post, CentOS 5.6's build 
had a particular build order dependency; it would have been very easy to 
build in the wrong order (which I did, on IA64).  Now, how, without 
modifying the GA NEVRA for each package from the upstream released NEVRA 
for that package, do you deal with a beta package that actually exposes 
a later version of an ABI than what GA needs to expose when it comes to 
upgrading to GA from the beta?  If you change NEVRA at all you run the 
risk of side-effects when updating to GA or updates later.  So you need 
to release a new package without changing NEVRA, but as far as RPM and 
yum are concerned it's the same package. The question boils down to a 
cost-benefit analysis; is the cost of having a beta, versus the 
benefits.  Up until now, at least, the CentOS project has not had a 
public beta process, but rather a closed QA team process.  This is 
characteristic of the project, and changing that involves other changes 
to support more transparency.

Now, having said that, Scientific Linux took the route of having betas 
and release candidates, and up until EL8 this was an alternative to 
CentOS, but not with EL8.

My own experience stems from being a Red Hat Beta Tester back in the 
days of the Red Hat Linux Boxed Sets; that was a closed beta team, and a 
fairly large one.  The CentOS QA testers are that team today, and yes it 
would be nice to see what the requirements for being a QA tester would 
be, and yes I believe there is good potential to help the core project 
in that area.  There are more opportunities in the SIGs; you've started 
along that path and I wish you well in it.

More information about the CentOS-devel mailing list