Description of problem: For the RHEL-5 kernel I wound up with a handful of new bugs on my lap that were in the ON_QA state but _not_ in the errata. Trying to figure out how that happened, I noticed people manually transitioning those bugs from ASSIGNED to ON_QA. After yelling at them, they pointed out the fact that they manually moved the bugs while the product was still in RHEVH. Later someone moved the bug from product RHEVH to RHEL-5 (it looks to be a bugbot). Anyway the flags were reset correctly, but now we have incorrect states. Because the state was not reset, the errata tool is never updated with the correct bz info. I can imagine this not only screwing up QE's process, but the bugs are never released to our customers so they never know if things got fixed, etc, etc. I have to deal with enough bugzilla accounting for the kernel, handling 800 bugs per update. This issue just gave me another headache, combined with the fact that I have no cli into the errata tool and things become difficult to verify that all the bugs that need to be there are there.
Trying to understand what needs to be done to fix this in the future. The bugs when under the RHEV product were put into the ON_QA state and *then* moved to RHEL propduct? You are proposing that ON_QA being special as it is, that when a bug changes product (from any product to any product) and it's current status is ON_QA, the status should be changed automatically to a different value? What should the new value be? the previous value? ASSIGNED? Also maybe a comment should be added as well stating why the change was made. Dave
Well not just ON_QA but MODIFIED too. I mean a whole slew of bugs were pushed to RHEL-5 kernel in the ON_QA state but were _not_ in the kernel, thus screwing up the QE process and all the other bugzilla accounting we do to manage 700 kernel bugs for an update release. I actually don't have a clue about how to fix this because I really don't know where the patches for these fixes went. On one hand a fix was committed to a package. Later on, the bugzillas are merged but what about the fixes in the package? Who guarantees those fixes are really there? Merging products in general doesn't seem like a good idea. Perhaps this is just a one off and we can chalk it up to 'lesson learned, don't do this again'. But I have no idea what goes on in those management meetings. :-)
Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and therefore this bug will need to be re-verified against the new release. With the updated code this bug may no longer be relevant or may have been fixed in the new code. Updating bug version to 3.4.
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can. Thanks Bugzilla Development Team
As part of the recent Bugzilla 2.4 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time. If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically. Thanks, the Bugzilla team.
As noted previously, the Bugzilla Team is cleaning up a large number of outstanding issues that have bit rotted. This bug is being closed as there has been no response to that notification. If you believe this bug is still important please reopen this bug in the NEW status and PM will consider it.