On 31 August 2015 at 00:15, Peter Stuge <pe...@stuge.se> 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
