From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A36C31384C0 for ; Sun, 30 Aug 2015 07:20:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 69278E087C; Sun, 30 Aug 2015 07:20:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4DD55E086D for ; Sun, 30 Aug 2015 07:20:06 +0000 (UTC) Received: from [192.168.1.2] (c-73-53-75-119.hsd1.wa.comcast.net [73.53.75.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zlg) by smtp.gentoo.org (Postfix) with ESMTPSA id 2C9BC34082B for ; Sun, 30 Aug 2015 07:20:04 +0000 (UTC) Subject: Re: [gentoo-dev] Better way to direct upstream bugs upstream? To: gentoo-dev@lists.gentoo.org References: From: Daniel Campbell Message-ID: <55E2AEA9.5080303@gentoo.org> Date: Sun, 30 Aug 2015 00:20:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: c804d75b-bfd6-43b4-a3b7-acdd4cbf1672 X-Archives-Hash: e2eb1e1f38d65450fe387e1cddeb74a4 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/30/2015 12:03 AM, Kent Fredric wrote: > On 30 August 2015 at 07:53, Matt Turner > wrote: >> >> Is there a better way of directing reporters to file bugs >> upstream? Of course it's not always clear whether a bug is an >> ebuild bug or something easily patched in Gentoo vs a driver bug >> that requires an upstream developer... > > > 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. > > Its also not always abundantly clear to end users where upstream > is, and there are potholes in that process. For instance, in Perl > space, the "Current upstream reporting que" is often RT, but it can > be github, and knowing exactly where the reporting queue > *currently* is something that can't be reliably replicated in > metadata.xml, because it can change on a whim, and sometimes the > metadata visible on the CPAN sources is also wrong, and requires an > experienced developer to chase its tail to work out where it > currently is. > > And there are some upstreams on CPAN where there is no documented > or stated bug reporting mechanism, and in such cases, the metadata > will encourage you to use the defacto standard, RT, and doing so > for some upstreams will get you automated mails that will possibly > make the reporter recoil in a corner for a bit. > > I know and have had moderate success in dealing with upstreams > like that, because I've worked out from listening to people talk > how/where to actaully talk about problems and try to work out how > to say things in a way that will work. > > ( That is, I'm a much better reporter at reporting faults found in > gentoo to some upstreams than any user could hope to be ) > > There are also cases where users reporting direct to upstream just > irritates upstream, because its a breakage/potential breakage due > to something gentoo does, and you have the whole hostile "not our > problem, you're on gentoo, you get to keep the pieces" response. > > For these reasons, I think its best that those with the most > knowledge of how upstream works, ( us, the developers ) handle > reports from end users and ferry them upstream. > Quick question: what is RT? Regarding that, I've noticed that multiple upstreams (apparently urxvt being one) have an issue with Gentoo and how 'problematic' we are as a distribution because we offer so much choice to users. I'm not sure I understand that attitude since makes upstreams look like they don't care about the configurability of their own software. If Perl packages and CPAN have similar issues, how do you guys handle it in perl-space? I think if I was dealing with a difficult upstream, I'd try to figure out what I could do to help their build scripts improve. If they were unresponsive to criticism or offers for improvement, I would reroute bugs their way. Historically, what is our approach to stubborn upstreams that think Gentoo is the problem instead of their build scripts or packaging preferences? Do we have a policy regarding difficult upstreams? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV4q6kAAoJEAEkDpRQOeFwin4QAMKIC2WwOlfdsZ1U9WKnmgP1 Aussqt36Fcw4HR50lJ4rqxmkax2QIbF7msDjR/keoW9ZQ/IjcCObXy5XATthw2lJ g2nNS3TLKRtpQxA4baZsZqlLUpPOTNOKm7KArA9e1PCfELdViVD9aSlYWGfmz0Ns efcXJUjN22uHgx2Awqpj9+jg1o/wgonnryYwMAHxvzfFeIdVd9zV4Af8IyXz7Qh9 tp1/UfMLYE/40sne7NVd/2sZpJHFD0WW8ViPEYkJFtYySwR3KRwNfu/S/7iLhiKB pG5Mqneq0taN4EWXYX7wSG6w5dr5EWMiN5ftPI/mXDSfElTZY7H6U4KjXMi5eNU2 Wm8HjfrGtTm8pOJhd1EZ9otBSCWVGySTEeTGFEUEQokMor62Ff9/jVCB20hw6Hrf oP79U+VyZlLcejW9kCEP+dUdnjLgO81uxLbcp3r35A05lwgUPnLltT+9/nFwY6ut VgEWxUNHrIsr6eUTZQ53OeB/VDxf3yyJcIg1ysdN9jGVHM/W5/DuDCe+/sttOMD1 7C/wGLVfltZEVets2EAr+ks76sTG8/Miurr79J/f07Z8TU1qKhjyCri2+7cuIuOZ B51HQ1NdI9TNEa68/c7MKtKwYLfwQTcEndQgRnRL8ZDLGPMZIJuKDKUb5OHsWilC Xc53D+mRG+YGy+rcL73E =QWFf -----END PGP SIGNATURE-----