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?
- Ken
On Tue, Jan 5, 2021 at 10:02 AM Ken Dreyer kdreyer@redhat.com wrote:
Hi folks,
This RHBZ tracks a problem in CentOS Stream: https://bugzilla.redhat.com/show_bug.cgi?id=1901449
Whoops, I should have pasted that the Stream bug is actually 1908275, and *that* one was closed as a duplicate of the RHEL bug at 1901449. Hopefully you get the idea :)
- Ken
On Tue, Jan 5, 2021 at 12:03 PM Ken Dreyer kdreyer@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.
On Tue, Jan 5, 2021 at 12:06 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 5, 2021 at 12:03 PM Ken Dreyer kdreyer@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.
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.
josh
On 05/01/2021 17:17, Josh Boyer wrote:
On Tue, Jan 5, 2021 at 12:06 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 5, 2021 at 12:03 PM Ken Dreyer kdreyer@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 ...
I think the Stream team are still formulating some contribution guidelines and this might be something to consider as part of that work.
It does not help when the Stream bug is closed as a duplicate and the linked one is not accessible to anyone outside Red Hat.
Trevor
On Tue, Jan 05, 2021 at 05:32:14PM +0000, Trevor Hemsley via CentOS-devel wrote:
It does not help when the Stream bug is closed as a duplicate and the linked one is not accessible to anyone outside Red Hat.
If this happens, please comment about it. Often those bugs can be opened.
On Tue, Jan 5, 2021 at 10:06 AM Matthew Miller mattdm@mattdm.org wrote:
On Tue, Jan 05, 2021 at 05:32:14PM +0000, Trevor Hemsley via CentOS-devel wrote:
It does not help when the Stream bug is closed as a duplicate and the linked one is not accessible to anyone outside Red Hat.
If this happens, please comment about it. Often those bugs can be opened.
-- Matthew Miller
Request submitted:
https://bugzilla.redhat.com/show_bug.cgi?id=1908275#c9
Akemi
On Tue, Jan 5, 2021 at 12:50 PM Akemi Yagi amyagi@gmail.com wrote:
On Tue, Jan 5, 2021 at 10:06 AM Matthew Miller mattdm@mattdm.org wrote:
On Tue, Jan 05, 2021 at 05:32:14PM +0000, Trevor Hemsley via
CentOS-devel wrote:
It does not help when the Stream bug is closed as a duplicate and the linked one is not accessible to anyone outside Red Hat.
If this happens, please comment about it. Often those bugs can be opened.
-- Matthew Miller
Request submitted:
https://bugzilla.redhat.com/show_bug.cgi?id=1908275#c9
Akemi
Thanks for the request, individual requests like this help a lot while we're working on how private bugs are handled.
--Brian
On Tue, 2021-01-05 at 12:57 -0600, Brian Stinson wrote:
On Tue, Jan 5, 2021 at 12:50 PM Akemi Yagi amyagi@gmail.com wrote:
On Tue, Jan 5, 2021 at 10:06 AM Matthew Miller mattdm@mattdm.org wrote:
On Tue, Jan 05, 2021 at 05:32:14PM +0000, Trevor Hemsley via
CentOS-devel wrote:
It does not help when the Stream bug is closed as a duplicate
and
the linked one is not accessible to anyone outside Red Hat.
If this happens, please comment about it. Often those bugs can be
opened.
-- Matthew Miller
Request submitted:
https://bugzilla.redhat.com/show_bug.cgi?id=1908275#c9
Akemi
Thanks for the request, individual requests like this help a lot while we're working on how private bugs are handled.
Can this be automated? e.g. "if a public bug is closed as a dupe of a private bug, Bugzilla should warn before taking that action, and suggest cancelling or making the private bug public"
Regards,
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?
Cheers, Alex
On Tue, Jan 5, 2021 at 1:00 PM Alex Iribarren alex.m.lists3@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.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Jan 5, 2021 at 1:03 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 5, 2021 at 1:00 PM Alex Iribarren alex.m.lists3@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
On 05/01/2021 18:02, Neal Gompa wrote:
On Tue, Jan 5, 2021 at 1:00 PM Alex Iribarren alex.m.lists3@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 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?
On Tue, Jan 5, 2021 at 2:34 PM Phil Perry pperry@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@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
On Tuesday, January 5, 2021 11:06 AM, Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jan 5, 2021 at 12:03 PM Ken Dreyer kdreyer@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.
-
Akemi Yagi -
Alex Iribarren -
Brian Stinson -
Josh Boyer -
Ken Dreyer -
Matthew Miller -
Michel Alexandre Salim -
Neal Gompa -
Phil Perry -
redbaronbrowser -
Trevor Hemsley