On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso <amoralej at redhat.com> wrote: > > > Hi, > > On Thu, Jan 21, 2021 at 3:01 PM Josh Boyer <jwboyer at redhat.com> wrote: >> >> On Thu, Jan 21, 2021 at 5:35 AM Alfredo Moralejo Alonso >> <amoralej at redhat.com> wrote: >> > >> > Hi, >> > >> > With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos. >> > >> > While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy. >> > >> > What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board? >> >> This is indeed a great question and yes, we are already discussing it >> internally. To be quite frank, we've been discussing it for quite >> some time and long before the CentOS Linux announcement. There is a >> balance to be struck between making CentOS Stream a viable platform >> for ecosystem development, and faithfully representing what will >> become the next RHEL minor release. >> >> To date CentOS Linux and CentOS Stream have both stuck to "we provide >> what RHEL provides" so that anyone consuming them gets parity with >> RHEL. This benefits users that have a mixed RHEL/CentOS environment, >> and developers targeting the next release of RHEL by using CentOS >> Stream because they build against what RHEL has available. It >> prevents them from inadvertently getting themselves into situations >> where an application or package may build on a CentOS flavor, but fail >> to run on RHEL due to missing dependencies or, less noticable, running >> against unsupported content. >> > > Putting all "unsupported" content in a separated -unsupported repo which would be disabled by default could be a suitable solution (similar to current Devel but automatically populated with unshipped content on each new build). It's not a bad suggestion, but experience shows that naming or including "unsupported" in a repo or a package name doesn't mean much. If people can install it, they will. Also, we largely did that in RHEL 7. It is called the Optional repo and the content in there is unsupported. Let's just say it was not the deterrent that was originally envisioned and led to a number of problems. >> However, we have seen, and I have personally evaluated, MANY requests >> for some of the unshipped packages for what are very valid reasons. >> By working with the CentOS team, we have slowly adjusted our default >> approach to these requests and we're continuing to evolve it. I will >> be working further with them to figure out how best to strike this >> balance, particularly in light of CentOS Stream 9 coming and the >> increased emphasis on using that directly for RHEL development. >> >> I can promise no timelines and we have nothing concrete to share at >> the moment, but please know we're taking this seriously and the >> information the community is providing on what use cases they are >> trying to solve is actually critical to coming up with the right >> solutions. The more we know about how our users leverage our projects >> and products, the better we can make them. Thanks in advance for your >> patience. >> > > Is there any ticket (bugzilla or whatever) where I could track the progress of the discussions? At the moment, nothing that is public. This is larger than a bug at any rate. Perhaps once there's a process for CentOS Stream community requests or interests that are larger in scope, someone could take the time to write up something that we can use to facilitate that discussion. josh