On Wed, Jan 8, 2020, at 16:25, Gordon Messmer wrote: > On 1/8/20 7:43 AM, Johnny Hughes wrote: > >> I don't think it's*entirely* fair to say that the fixes offered weren't > >> relevant to CentOS, when no one outside the core maintainers had access > >> to the build process, where fixes relevant to CentOS could be offered. > > That is because CentOS Linux (other than Stream) is a rebuild of RHEL > > source code .. so, that is how things get into base CentOS Linux. > > > Yes, I know. > > > > We don't accept input that deviates base CentOS Linux from RHEL source code. > > > Of course not. But that's not the point. Neal pointed out that the > process of debranding and rebuilding CentOS is not a community process, > and that the user community takes and does not give back much. That is > true. I agree with him. > > I don't, however, know a good reason to believe that the community > doesn't want to contribute, or isn't capable of contributing. I have > seen people offer to contribute numerous times, especially when new > major or minor releases lag far behind upstream. I tend to think those > lags are evidence that the project does need more contributors, but I > simply don't know any way for capable people to access the work queue > and assist in getting it done. > > When I look at https://wiki.centos.org/Contribute , I don't see any > entry points for capable people to participate early in the process. I > see a note that testing packages are announced on the devel list, but > that's pretty far along in the process. It's hard to imagine that > participating at that point will significantly improve the turnaround > time for the process of rebuilding and publishing the system. > > I could be wrong, since I see the situation from the perspective of the > user community that I'm a part of, but my point is that Jim said "there > wasn't really much of a way to give back that didn't make the project > deviate from its core mission" and that is literally true. I'm not > arguing otherwise. I just want to suggest that the fact that there > wasn't a way to give back without deviating from the core mission is the > result of decisions that the developers made to keep the process very > closed and private, and we should acknowledge that when we're discussing > community contributions. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > Most of the delays for 8.x are related to the way we literally put CentOS together (buildsystem, compose, delivery), and major shifts in the technology that makes up Enterprise Linux (modules). Neither of these things are really ripe for large-scale contribution in CentOS Linux, although some of the decisions that were made at this layer put us in a better place for when CentOS Stream is fully realized. I understand some of the frustrations mentioned here, taking the example of seeing the builds and not being able to download binaries we can look backwards at previous releases: - in CentOS 6 there were no public logs at all - in CentOS 7 there were public but somewhat hard to discover logs (buildlogs.centos.org) - in CentOS 8 there are public logs with a relatively familiar frontend (koji), with binaries hidden by a configuration option Are we finished? absolutely not, but I don't want to discount the progress we've made, especially when we measure progress against 15 years worth of build/release processes that we're actively evaluating, and given that configuration options like this can be changed easily. One goal that drove some of the decisions at the beginning of CentOS 8 was to refocus building the distribution itself around some on familiar tools. Koji, pungi, and dist-git (git.centos.org) are a lot more familiar to Fedora and RHEL workflows than reimzul and SRPMs. In the past buildsystem and tooling has been part of what has made releases so jarring for us, and coming closer to familiar workflows now lets us factor out some of those differences as we grow CentOS Stream and deal with future releases. Refactoring systems takes time, is messy, and we made some tradeoffs, but the intent was and is to make transparency and contribution easier in a way that helps us think critically about the way we've done things in the past. -- Brian Stinson