> On May 3, 2017, at 00:55, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > >> On Wed, 2017-05-03 at 00:51 -0400, Eric Griffith wrote: >>> On May 3, 2017, at 00:34, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: >>> >>>> 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. >> >> Other than more point releases and more branches, what's really the >> solution? I only see three real options: we convince upstream to do >> more point releases; we 'fork' it and do our own point releases, >> regardless of upstream; or we just bite the bullet and always ship >> latest Gnome, even if that means bumping major versions. >> >> Is there a fourth option to you, Adam? Other than the status quo I mean. > > Apply patches to downstream package builds. It's not that difficult, > and we do it relatively often. But it requires someone to care about > downstream, and it has to be *tracked* downstream, which is the point > of this subthread. It's not appropriate for an upstream bug tracker; so > far as the *upstream* tracker is concerned, the bug's fixed as soon as > the commit hits git master, usually. Fair enough, guess now the question just comes down to if we have people who care enough to do the patching, but also the time to track bug fixes committed to upstream git master for all the big gnome components. _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
