On Wed, 2017-05-03 at 00:51 -0400, Eric Griffith wrote:
On May 3, 2017, at 00:34, Adam Williamson
<adamwill(a)fedoraproject.org> 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(a)fedoraproject.org> 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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net