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 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?