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
