[gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Duncan]

Kent Fredric posted on Sun, 30 Aug 2015 19:03:37 +1200 as excerpted:

> I've always seen it as a case where Gentoo devs stand as a layer of
> sanitization between downstream and upstream.
>
> Wherein reporting things upstream is good, but having a downstream
> tracker for it is also good, so that when the bug is resolved upstream,
> that the consequences of it are known to be propagated downstream.
>
> And if upstream refuses to fix a bug, Gentoo devs have to choose how to
> handle that problem for downstream, sometimes patching around it, or if
> that is not simple, or not possible,
> to provide blockers where necessary, or produce end-user-visible
> warnings about problematic behaviour, etc.
>
> So, even in the case users are prompted to file bugs upstream first,
> they should also at minimum report to gentoo when the bug is resolved
> upstream so that the fix can be replicated.

In addition to the other services a distro provides, a big one is having 
one single place to file bugs, instead of a couple hundred different bug 
tracker accounts on a half-dozen tracker software bases, and that's not 
even counting the ones (like the perl trackers that Kent mentions) that 
are virtually impossible for a user to find at all.

This is a big deal that I think some gentoo package maintainers forget 
about sometimes.  The maintainer should be familiar with package upstream 
and know where to file bugs, as well as probably already having a bug 
reporter account.  Users are unlikely to, because as I said, it'd end up 
being a couple hundred accounts scattered all over the place.  But users 
probably already do have a gentoo bug account, and if they don't, setting 
it up once to use for all those hundreds of packages instead of a couple 
hundred times... makes a difference.  As a result, a user told to file a 
bug upstream may well simply blow it off and wait out the bug, which 
someone else will likely eventually report, but look at all the time that 
is needlessly going by on a bug that could actually be in the process of 
being fixed, in the mean time.


Both for that reason and because I often /don't/ know whether it's a 
gentoo bug or not, I default to filing with gentoo.  However, where the 
details are specific enough that I know it's an upstream bug, 
particularly if it's urgent, I'll often go to the trouble of filing 
upstream as well, then referencing each bug in the other filing.  When I 
do so, whichever one gives me a patch to test or whatever, first, I try 
to update the other one, both with the mention of the patch and the 
results of my test with it.  Among other reasons, I never know when other 
gentooers are going to be running into the problem, and if/when I know of 
a patch available, I want it on the bug, so they too can drop it in /etc/
portage/patches/ and get a fix, often before the maintainer gets around 
to patching the gentoo package.  I know I've found enough fixes already 
available on bugs filed by others, and am simply paying it forward. =:^)

FWIW the two most recent bugs I've handled this way were systemd bugs, 
one a networkd bug on IPv4-only setups, the other a tmpfiles.d bug that 
only affected users on btrfs, both related to changes originally found in 
218, IIRC, with the fixes making 220.  Awhile before that was a rather 
nasty gmime related bug, in 2.6.16, IIRC, "nasty" because people with the 
affected version were posting messages that broke the RFCs, thus 
affecting many others attempting to read those messages.  The details on 
all three bugs were specific enough that once upstream took a look, the 
bug was easily reproduceable and thus reasonably quickly fixed.

Of course other bugs I report upstream because I'm already involved with 
upstream, or want to be by the time I find and file a bug.  I've never 
used gentoo kernel packages, for instance, having learned to build my own 
back on mandrake, and simply adjusted as necessary when I switched to 
gentoo.  All my kernel bug reports have thus been upstream, during the rc 
cycle before upstream release, with all but one fixed before release and 
that one fixed in another kernel cycle. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman