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