<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 12/15/2020 6:18 PM, Brendan Conoboy
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAKzUzueswy6i2pxU+VC5HMjS1MCGLnWb+HLPuDVa-8eM1ym0Kg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">On Tue, Dec 15, 2020 at 5:42 PM Mauricio Tavares
          <<a href="mailto:raubvogel@gmail.com"
            moz-do-not-send="true">raubvogel@gmail.com</a>> wrote:<br>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">On Tue, Dec 15, 2020 at
            6:30 PM Jason Brooks <<a href="mailto:jbrooks@redhat.com"
              target="_blank" moz-do-not-send="true">jbrooks@redhat.com</a>>
            wrote:<br>
            ><br>
            [...]<br>
            > No. I was on that team too, and growing CentOS beyond
            just consumption<br>
            > and into contribution was something we emphasized
            throughout. Our<br>
            > primary intent, the reason the whole thing got started,
            was that we<br>
            > needed to provide our layered projects with a
            slow-moving community<br>
            > distro to layer atop. That's why we put so much effort
            into the SIGs,<br>
            > and into opening up the build processes and tools. Even
            with that work<br>
            > done, until we opened up RHEL development itself,
            contributions to the<br>
            > core of CentOS were basically blocked. Now, in addition
            to the layered<br>
            > project need, which hasn't gone away, we need a distro
            to open up RHEL<br>
            > development, and CentOS Stream is that distro.<br>
            ><br>
                  Isn't that what fedora is used for?</blockquote>
          <div><br>
          </div>
          <div>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.</div>
        </div>
        <br>
      </div>
    </blockquote>
    <p>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?<br>
    </p>
    <p>But beyond that, the above statement does not seem to be
      compatible with the following:</p>
    <div class="moz-cite-prefix">On 12/15/2020 3:35 PM, Johnny Hughes
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:dd6e13e8-c347-b4b7-b113-aa93a386bca6@centos.org"><br>
      <pre class="moz-quote-pre" wrap="">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.
</pre>
    </blockquote>
    <p>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.</p>
    <p>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.</p>
    <p>-jc<br>
    </p>
  </body>
</html>