On 12/15/2020 6:18 PM, Brendan Conoboy wrote: > On Tue, Dec 15, 2020 at 5:42 PM Mauricio Tavares <raubvogel at gmail.com > <mailto:raubvogel at gmail.com>> wrote: > > On Tue, Dec 15, 2020 at 6:30 PM Jason Brooks <jbrooks at redhat.com > <mailto:jbrooks at redhat.com>> wrote: > > > [...] > > No. I was on that team too, and growing CentOS beyond just > consumption > > and into contribution was something we emphasized throughout. Our > > primary intent, the reason the whole thing got started, was that we > > needed to provide our layered projects with a slow-moving community > > distro to layer atop. That's why we put so much effort into the > SIGs, > > and into opening up the build processes and tools. Even with > that work > > done, until we opened up RHEL development itself, contributions > to the > > core of CentOS were basically blocked. Now, in addition to the > layered > > project need, which hasn't gone away, we need a distro to open > up RHEL > > development, and CentOS Stream is that distro. > > > Isn't that what fedora is used for? > > > Fedora is used as a starting point for major release alphas and betas, > i.e., 7.0 Beta, 8.0 Beta, etc. After the major release beta comes out > all automatic connection between Fedora and RHEL ceases. RHEL 8.2 was > based on 8.1 + upstream changes, 8.1 was based on 8.0 plus upstream > changes. There simply hasn't been a place where people outside the > Red Hat firewall can see, use, and influence the direction of the next > minor release, as it is being created. That's what Stream is meant to do. > Minor release updates very rarely have a need for significant influence, but I'm unsure how this is supposed to relate to actual RHEL minor version Beta releases. Will there still even be RHEL 8.x Beta Releases? But beyond that, the above statement does not seem to be compatible with the following: On 12/15/2020 3:35 PM, Johnny Hughes wrote: > > You guys keep calling it beta .. it is not. > > The RHEL team is not grabbing brand new software (like the do in > Rawhide, for example) and trying to roll that into RHEL. They are going > to do one of three type of updates. > > 1) A security update > > 2) A bugfix update. > > 3) An Enhancement update. > > For #1 and #2 .. you want those rolled in and you want them rolled in > ASAP. RHEAs do not make up that many of the updates. You are getting > these after QA testing a couple months early at most. There's no meaningful "influence" at this point beyond filing BZs about things that break. While that's certainly better than nothing, if RedHat wanted to accept bugs from non-RHEL binaries, especially in-house rebuilds explicitly targeting 100% binary compatibility, it could easily have done so at any point in the past. There's still a conflation of upstream and downstream here. The "direction" of any aspect of RHEL is already going to be quite set by the time it gets into CentOS Stream... as is appropriate for a downstream. -jc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201215/8d8e7550/attachment-0005.html>