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 18FD81384C0 for ; Sun, 30 Aug 2015 12:38:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 205BD14294; Sun, 30 Aug 2015 12:38:14 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EEEC814217 for ; Sun, 30 Aug 2015 12:38:12 +0000 (UTC) Received: by obcid8 with SMTP id id8so24904041obc.0 for ; Sun, 30 Aug 2015 05:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BddqIeKBDIesoTRs/DehQ2USLayqCuepJ0SzgBmHm18=; b=OjKraR6xFu/gIInhf3i0hKin6YxFHTDrD5DByhTz2p2lfe1NclgoJF0AuKP0z65OK8 CBAr410Ef2lW7WXHW/icUE+AJDQxJ1ukq0LYbusRRinaxxRRbi1yZvkcZFzqrlvHtGuy bblkKcnB984N3KUI7/tV81SGb5/lGJpJjBW9v8M6ZesLV4mRRLETv1lOKdcDEgm5dtyR MFi3wSybtclhHEUZ8776KcRQ26B9pNxAqQXmx0lthx6VetQSG6C9oOGO/w43/CY2/SAb hKPdQMdaguhBrvfMuJ/pQKdPd2EhhsFYtP9ooBq5X5Bc1GuQhOXAuOqTcIPKaGD3kpZK p4zQ== 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 X-Received: by 10.60.50.133 with SMTP id c5mr11445131oeo.24.1440938292413; Sun, 30 Aug 2015 05:38:12 -0700 (PDT) Received: by 10.202.106.72 with HTTP; Sun, 30 Aug 2015 05:38:12 -0700 (PDT) In-Reply-To: <20150830121527.9012.qmail@stuge.se> References: <20150830121527.9012.qmail@stuge.se> Date: Mon, 31 Aug 2015 00:38:12 +1200 Message-ID: Subject: Re: [gentoo-dev] Better way to direct upstream bugs upstream? From: Kent Fredric To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: ecd906c9-626c-4060-9859-273609d9b661 X-Archives-Hash: 7082db6fa9233f72d8403336dd4f77b1 On 31 August 2015 at 00:15, Peter Stuge wrote: > In theory it can, but my experience is that in practice it doesn't > change very often. > > >> 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. > > Sounds like a task that the ebuild maintainer can solve? It can be done, just there are annoying edge cases where it doesn't work and any metadata will be wrong. - There are upstreams where there is no real contact address - There are upstreams where using automatically discernable defaults will get you a default that will get anyone who uses that contact address "Yelled at". - There are upstreams where the documented bug tracker in the discoverable metadata is wrong, and will require a new release to fix. - There are upstreams whos bug tracker I would *never* refer a user to, for instance, bug trackers on sourceforge are enough to make me go "Is there somewhere else I can throw my reports?" ( My ad blockers now block that whole domain due to its track record of being a safe haven to malware and deceptive advertising ) And the problem with the "Not a reliable data" is that you can't discover it until its a problem. Which means it won't be known its a problem until a user attempts to use it. Which means we're telling users to resolve a bug in resolving bug trackers before they can resolve a bug. My favourite class of these at present are the ones who were foolish enough to use Google Code for bug tracking, as the metadata for many projects *still* says its viable, and you follow the link and get a 403, and some of these don't *actually* have a decided upon alternative yet. I've just been tracking down the authors and doing it manually, or digging into the data to find their source control is mirrored on github and there's a defacto collection of people who have started filing bugs there instead, but its not authoritative yet. Yes, cases like these are exceptions, but they're exceptions that cause serious user confusion every time they happen. For a namespace like dev-perl/ and perl-core/, we could automate provisioning "an upstream" bug tracker for 90% of cases. But the remaining 10% that was provisioned from metadata would be wrong, and a sentience of some kind would be required to work out which 5% was wrong, and *not* to rely on the automated provisioning. And there are some authors on CPAN who I would institute a custom black hole stipulating that they should *only* contact gentoo about bugs and *never* upstream, because upstream have a marked track record of setting people who report their bugs on fire *due* to them being gentoo users. Its cool that there are lots of upstream who are capable and willing to deal with gentoo users directly. But the odds of a gentoo user assuming any upstream able /willing to be responsive and them getting unhelpful responses and the Gentoo user not realising they needed flame retardant clothing, makes me want to suggest a system wherein direct upstream contact by Gentoo users should be something decided upon based on the gentoo users technical competence. If for example, a Gentoo user is able to function at the level expected of a Gentoo developer, and are able to dig into the problem sufficient to isolate and comprehend the problem in a systems agnostic way, or at least express how and why Gentoo changes the behaviour of a system, then by all means, going straight to upstream should be fine, and they can ask for a revision bump once the problem is fixed, and if they're feeling generous, put a copy of their issue on bgo with possible solutions, because that is where gentoo users look first. But we shouldn't expect this level of performance from all users, and we should be capable and willing to try helping the less capable with reporting their issues to upstream. Some of this is just basic due dilligence, making sure the user has even reported the right information. If a user isn't able to provide information to gentoo sufficient that gentoo can even identify that a bug is in fact happening, they're just going to be irritating upstream, because upstream won't be able to easily plumb the gentoo specifics to make sure they haven't just done something dumb that gentoo has already put guards against that the user has unwittingly disabled. -- Kent KENTNL - https://metacpan.org/author/KENTNL