[CentOS-devel] should we expect to close CentOS Stream bugs as dups of RHEL?

On Tue, Jan 5, 2021 at 1:03 PM Neal Gompa <ngompa13 at gmail.com> wrote:
>
> On Tue, Jan 5, 2021 at 1:00 PM Alex Iribarren <alex.m.lists3 at gmail.com> wrote:
> >
> > Hi all,
> >
> > On 1/5/21 6:17 PM, Josh Boyer wrote:
> > >> In my opinion, bugs for CentOS Stream should not be closed in favor of
> > >> RHEL 8.4 bugs (or any future unreleased RHEL 8.x bugs). Instead it
> > >> should be the other way around. The pipeline for changes to RHEL means
> > >> that RHEL 8.4 bugs should be closed as dupes of CentOS Stream ones.
> > >
> > > That's a reasonable perspective, but often the RHEL bug has been
> > > around for quite some time and has far more relevant data to the issue
> > > at hand.  It's not really about RHEL vs. Stream, but rather which bug
> > > has the most useful information.
> > >
> > > I think the Stream team are still formulating some contribution
> > > guidelines and this might be something to consider as part of that
> > > work.
> >
> > If Stream is truly to be RHEL's upstream, shouldn't the bugs be opened
> > against Stream in the first place?

For some bugs, yes.  There will always be a subset that can't be
opened there because of embargoes or partner NDA, etc.

> That does make sense actually. It might make more sense to stop having
> unreleased point releases populated in RHBZ and force those to use
> CentOS Stream "version" in RHEL 8 product in Bugzilla.

I don't think so.  The thing to keep in mind is that while it is
simple to make statements like that, it's actually much harder to just
flip a switch and have it be reality.  That's the case for many
reasons, but largely it boils down to the fact that bugzilla and RHEL
process have been intertwined for more than a decade, and the tooling
that we depend on to ship a product to our customers has certain
assumptions built in.  We still need to ship and support a product.

With Stream, we're open sourcing large portions of this and we'll have
to figure out where the balance lies.  Keep the suggestions coming
though.

josh