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

Tue Jan 5 20:10:20 UTC 2021
Josh Boyer <jwboyer at redhat.com>

On Tue, Jan 5, 2021 at 2:34 PM Phil Perry <pperry at elrepo.org> wrote:
>
> On 05/01/2021 18:02, Neal Gompa 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?
> >>
> >
> > 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.
> >
> >
>
> Absolutely - how can it make sense to assign a bug to something that
> does not exist. RHEL 8.4 will not exist until the day it is publicly
> released. The 'development' of RHEL 8.4 is now Stream, so any bugs

That is valid from a public perspective, but not entirely accurate.
RHEL 8.4 will not be available until the day it is publicly released.
It still exists.

> relating to the development of RHEL 8.4 are Stream bugs and 8.4 as a
> version should not exist until it's been officially released.
>
> Being really clear on that will prevent duplicate bugs being filed
> against multiple versions (8.4 and Stream) and collate all the useful
> information in one publicly accessible bug.
>
> Do we need to file a bug to remove future versions of RHEL from the bug
> tracker, or can someone make that happen?

We are not going to do that.  There are business implications and
necessities that need to be accounted for.  Let me explain a tiny bit
why.

We have an obligation to our customers to validate and verify that any
change we land in RHEL was done intentionally.  This is currently
implemented in a set of tooling in various measures, but part of that
is ensuring that a change that goes into a release is truly meant to
go into *that* specific release.  The tooling will look for a proper
configuration against the bug or issue before allowing the change into
that release, including the proper version being set.  Again, the
release might still be under development, but it still exists.  It's
simply not accessible to customers or the public.

Beyond that, we have partners that file RFEs to implement changes in
specific RHEL minor releases.  They need the ability to request
something for a specific minor release long before it is publicly
available, hence the versions are present.  This helps Red Hat and our
partners develop an aligned plan on what content will go into specific
RHEL minor releases to meet our joint business needs.  Personally, I
think bugzilla is not the tool to do this kind of planning with, but
it's what we've used for a long time.

Further along the pipeline, we have to ensure that our support staff
is able to open bugs from relevant customer cases.  That means the
versions need to be available before release, or issues reported on GA
day or very shortly thereafter don't have the proper versioning
available.  There will always be a window where the release is
available in bugzilla before it is available.

Now, that being said, we can certainly look at defaulting to CentOS
Stream as the version or creating queries to help with the DUPLICATE
public/private problem.  However, we are not going to remove
unreleased versions from bugzilla at this time.

josh