On Sat, Jan 11, 2020, at 14:24, Gordon Messmer wrote: > On 1/10/20 7:19 AM, Johnny Hughes wrote: > > Well sure .. but that is also true for any Linux distribution. It's not > > like Ubuntu or Debian or Linux Mint (or anyone else) let community > > members build their distributions. > > > Debian and Fedora are exactly the kind of community-driven projects that > I think CentOS should be, but isn't. They have documented processes for > becoming a maintainer. Their package management is publicly available, > so their current status and activity level are clearly visible. Anyone > can fork a package, build and test their changes, and send suggested > changes back in the form of a pull request in order to contribute to an > existing maintainer without requiring access to build and publish their > changes to end users. > > CentOS does not have an onboarding process that I'm aware of, and does > not appear to believe it needs one. There is a "git.centos.org" system, > but all of the repos I looked at are empty (It's possible that's because > I'm not logged in. Logging in currently results in a fatal error. > Either way, it's disappointing). Koji is apparently gated to Red Hat QA > only, so there's no opportunity or mechanism to collaborate until very > late in the process. To be precise, Red Hat at-large has the exact same access to mbox (the koji that we use to build the distribution) as the rest of the community. It's the CentOS QA group (which includes a couple of members who happen to be Red Hat employees) that works with pre-release content for CentOS Linux. This is not much different from how content was handled in past releases, it's just now publicly obvious that builds are happening. > > Point being: I agree with the people in this thread who think it would > be premature to discontinue Fedora Server, until CentOS becomes a mature > community project. > > > > We are never going to allow other people to build things not in our > > validated systems and then sign and release it with CentOS Keys as > > CentOS Linux. That would be ridiculously stupid :) > > > Of course it would. I'm bewildered as to why you're even arguing that > point. It's possible that you think we are ridiculously stupid. It's > possible that you're arguing in bad faith. It's possible that you're > unfamiliar with the collaboration processes common across the entire > Free Software community. None of those would be to your credit, so I'd > love to hear another explanation. I think the pattern is different with CentOS Linux though. There isn't really much 'contribution' to be done because the idea is to match what comes from RHEL sources as closely as possible. We don't have individual package maintainers in CentOS because 99% of the time we can get builds through, the other 1% takes some targeted work from the QA group, or targeted contact with subject-matter experts from Fedora or RHEL. What you're noting as the desired collaboration model is to have community maintainers accepting patches either for new features, or to follow new upstream releases of whatever the package happens to be. That model is indeed widely practiced in other distributions and FOSS projects, but it is probably a better fit for CentOS Stream and with the SIGs; such a model is an antipattern, though, for CentOS Linux. --Brian