On Tue, 2017-05-02 at 20:59 -0500, Michael Catanzaro wrote: > On Tue, May 2, 2017 at 7:59 PM, Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > This would be a major problem for the release validation process. We > > need to be able to track the *downstream* status of release blocking > > fixes. An upstream bug is not a good way to do this. > > Probably the best solution is not to actually forbid filing bugs, but > to have a bot that adds a comment that the bug is unlikely to be > reviewed on Red Hat Bugzilla and instructing the user as to how to > report the bug upstream. Then we can just ignore that comment when we > need a bug for release validation purposes etc. OK. And to be honest, this isn't limited to release validation and blocker bugs. What generally happens when an RHBZ report gets kicked upstream is the bug gets fixed...upstream. Often it only gets fixed on git master, which means it will likely *never* get fixed in the Fedora release it was actually filed against. If we're lucky the fix might also be committed to the most recent stable branch, which is probably the GNOME in the most recent Fedora release, so if there's ever another point release on that branch (often there aren't any after .2), the fix might *eventually* make its way back to the most recent Fedora release. But if we're at .2, or the bug was filed on the previous stable Fedora release, the fix may well never actually make it back to the Fedora release the reporter is running without someone taking ownership and bugging people to commit to different branches, do point releases, and ship updates to Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
