Closing this as DEFERRED. The bug would need to be fixed in/for RHEL 8.6.0 and then we can make a decision whether to request a RHEL-AV z-stream. FWIW: in the future, let's not clone bugs to all release streams - the RHEL8 bug should have been moved to RHEL9 and once resolution was closer a decision to clone for RHEL8 made.
(In reply to John Ferlan from comment #3) > Closing this as DEFERRED. The bug would need to be fixed in/for RHEL 8.6.0 > and then we can make a decision whether to request a RHEL-AV z-stream. > > FWIW: in the future, let's not clone bugs to all release streams - the RHEL8 > bug should have been moved to RHEL9 and once resolution was closer a > decision to clone for RHEL8 made. Hi John, Do you mean we can only clone it to release stream when the original bz on RHEL9/RHEL8.6 is at least MODIFIED? We are sure that we need the fix to be backport to zstream, to support new Windows guest on RHEL-AV 8.4 for customer need. So even in this case we are still not allowed to clone the bz before we have a fix? Thanks, Qianqian
(In reply to Qianqian Zhu from comment #4) > (In reply to John Ferlan from comment #3) > > Closing this as DEFERRED. The bug would need to be fixed in/for RHEL 8.6.0 > > and then we can make a decision whether to request a RHEL-AV z-stream. > > > > FWIW: in the future, let's not clone bugs to all release streams - the RHEL8 > > bug should have been moved to RHEL9 and once resolution was closer a > > decision to clone for RHEL8 made. > > Hi John, > > Do you mean we can only clone it to release stream when the original bz on > RHEL9/RHEL8.6 is at least MODIFIED? We are sure that we need the fix to be > backport to zstream, to support new Windows guest on RHEL-AV 8.4 for > customer need. So even in this case we are still not allowed to clone the bz > before we have a fix? > > Thanks, > Qianqian Allowed is probably too strong of a word - I would say I would prefer to not clone until we have a better idea of where the fix needs to be applied and where we are within the stages of the various releases. IOW, try not to follow some script/process to clone everywhere just because that's what we've always done. The problem is 3 bz's get created and not always assigned to the same person (which happened in this case, although 1 was assigned to Meirav who is Marek's manager). Furthermore in this case you cannot clone to create/request z-stream - that's a different process. I've tried to mitigate the multi-person ownership, but I'm not always successful. FWIW, during RHEL7/RHEL8 I saw the same essential problem assigned to 3 different engs. The one who created the fix and admits in one of the bugs - I have no idea where this fix should go it's too confusing. When a bug is created there's no guarantee it will get an immediate fix - sometimes the resolution takes a while - sometimes longer than a release cycle. The real problem is the discussions that take place in the bug(s) after the clone. Sometimes they are copied between the bugs, but more often than not they are not - so now there's 2 or more discussions taking place - sometimes disjoint... Sometimes links are created to point at the other discussion... Sometimes good information is lost or someone forgets which of the bugs they logged information - in the long run it's still just 1 problem that yes occurs and should be fixed in multiple releases, but we haven't determined where yet... I understand the QE side and I agree we want to see a bug fixed in multiple places. Still with the way we're working the 8.6/9.0 releases as simultaneous rebases of the same qemu-kvm it's more likely that a problem will exist in both releases. What's perhaps more interesting is if it doesn't exist in one or the other. As an engineer then it's a process of elimination as to what's different. We've told engs that fixes should go into RHEL9 first and RHEL8 second - both are important, but RHEL9 is the future. In my view, once we know we have a possible fix, then we should determine which releases will need the fix and then do the clones. Perhaps MODIFIED is too far into the process, but we don't know for sure. If a resolution is found before the rebase occurs, then both 8.6 & 9.0 would get the fix - so one can move one bug to POST, then clone as "TestOnly" to the other release in POST. After that we can decide between eng&qe along with the product owner whether a z-stream is necessary / possible and which releases to have the zstream. Some fixes are really tricky to backport and may cause other regressions - so we need to be smart about that. A fix that would come after the rebases occurs would go thru a similar process - once we know we have a fix upstream, we can clone the bug to the other release and do the backport of the fix to both downstream git repos. Doing that at the same time has lots of benefits for review and testing purposes. If we're "too close" to ITM26 (e.g. code freeze), then we have to make some other decisions. Again, it's about being smart with respect to where we are in a release cycle. Hope this helps - it's a slightly different mindset and certainly not a perfect solution. If someone feels more comfortable cloning bugs, then that's fine. I will work on closing RHEL-AV bugs though since we're not focusing there and the z-stream process is being managed by Yash and myself. It involves cloning a RHEL bug to RHEL-AV in order to create the z-stream bugs for AV and then closing the RHEL-AV clone as a duplicate of the RHEL bug. We are working around the tool that doesn't allow us to create a RHEL-AV z-stream from a RHEL bug.
Hi Jonn, Thanks a lot for your detailed explanation, and sorry for the inconvenience. I will wait for the further process regarding https://bugzilla.redhat.com/show_bug.cgi?id=2020133#c7 Regards, Qianqian