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

redbaronbrowser

redbaronbrowser at protonmail.com
Wed Jan 6 08:46:13 UTC 2021


On Tuesday, January 5, 2021 11:06 AM, Neal Gompa <ngompa13 at gmail.com> wrote:

> On Tue, Jan 5, 2021 at 12:03 PM Ken Dreyer kdreyer at redhat.com wrote:
>
> > Hi folks,
> > This RHBZ tracks a problem in CentOS Stream:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1901449
> > Today someone closed it as a duplicate of RHEL 8.4:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1901449
> > When is it appropriate to track a bug against RHEL 8.4 vs CentOS Stream?
> > What do we expect community members (inside and outside RH) to do in
> > these cases?
>
> 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.

I would suggest that nether be closed out.

The Stream bug should remain open to work on the best possible long term solution.

However, closing a RHEL bug as a dup may risk sending the wrong message to the customer.  Take for example a discussion in the Stream bug determines a modification to glibc best addresses the problem.  If the RHEL bug is closed it would imply the RHEL customer needs to upgrade to a Stream glibc as being the recommended immediate fix.

Unless RHEL support is comfortable with treating something like a Stream 8.5 glibc on RHEL 8.4 as an officially supported configuration, closing the RHEL bug should probably be avoided.

Instead, Stream should be treated as the long term fix with RHEL support still having obligations to provide options for a short term fix or work-around while leaving the RHEL 8.4 is an officially supported configuation.

Treatment of the two bugs as "dups" probably should be handled by Blocks / Depends-on bugzilla meta-data between the two.

At least that is how I see it as a customer.



More information about the CentOS-devel mailing list