On Tue, Dec 15, 2020 at 6:49 PM Japheth Cleaver cleaver@terabithia.org wrote:
On 12/15/2020 6:18 PM, Brendan Conoboy wrote:
On Tue, Dec 15, 2020 at 5:42 PM Mauricio Tavares raubvogel@gmail.com wrote:
On Tue, Dec 15, 2020 at 6:30 PM Jason Brooks jbrooks@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.
That's a very interesting and unexpected standpoint. Do you only use the features present in the .0 release?
Will there still even be RHEL 8.x Beta Releases?
We have one planned for 8.4. In the future, who knows?
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.
A security update
A bugfix update.
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.
I think you've succinctly expressed that we have not done a good enough job of painting and sustaining a picture of the potential breadth of CentOS Stream and what it could mean to add additional facets to the community's self identity.