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.