| 1 |
On 31 August 2015 at 00:15, Peter Stuge <peter@×××××.se> wrote: |
| 2 |
> In theory it can, but my experience is that in practice it doesn't |
| 3 |
> change very often. |
| 4 |
> |
| 5 |
> |
| 6 |
>> sometimes the metadata visible on the CPAN sources is also wrong, |
| 7 |
>> and requires an experienced developer to chase its tail to work out |
| 8 |
>> where it currently is. |
| 9 |
> |
| 10 |
> Sounds like a task that the ebuild maintainer can solve? |
| 11 |
|
| 12 |
|
| 13 |
It can be done, just there are annoying edge cases where it doesn't |
| 14 |
work and any metadata will be wrong. |
| 15 |
|
| 16 |
- There are upstreams where there is no real contact address |
| 17 |
- There are upstreams where using automatically discernable defaults |
| 18 |
will get you a default that will get anyone who uses that contact |
| 19 |
address "Yelled at". |
| 20 |
- There are upstreams where the documented bug tracker in the |
| 21 |
discoverable metadata is wrong, and will require a new release to fix. |
| 22 |
- There are upstreams whos bug tracker I would *never* refer a user |
| 23 |
to, for instance, bug trackers on sourceforge are enough to make me go |
| 24 |
"Is there somewhere else I can throw my reports?" ( My ad blockers now |
| 25 |
block that whole domain due to its track record of being a safe haven |
| 26 |
to malware and deceptive advertising ) |
| 27 |
|
| 28 |
And the problem with the "Not a reliable data" is that you can't |
| 29 |
discover it until its a problem. |
| 30 |
|
| 31 |
Which means it won't be known its a problem until a user attempts to use it. |
| 32 |
|
| 33 |
Which means we're telling users to resolve a bug in resolving bug |
| 34 |
trackers before they can resolve a bug. |
| 35 |
|
| 36 |
My favourite class of these at present are the ones who were foolish |
| 37 |
enough to use Google Code for bug tracking, as the metadata for many |
| 38 |
projects *still* says its viable, and you follow the link and get a |
| 39 |
403, and some of these don't *actually* have a decided upon |
| 40 |
alternative yet. I've just been tracking down the authors and doing it |
| 41 |
manually, or digging into the data to find their source control is |
| 42 |
mirrored on github and there's a defacto collection of people who have |
| 43 |
started filing bugs there instead, but its not authoritative yet. |
| 44 |
|
| 45 |
Yes, cases like these are exceptions, but they're exceptions that |
| 46 |
cause serious user confusion every time they happen. |
| 47 |
|
| 48 |
For a namespace like dev-perl/ and perl-core/, we could automate |
| 49 |
provisioning "an upstream" bug tracker for 90% of cases. But the |
| 50 |
remaining 10% that was provisioned from metadata would be wrong, and a |
| 51 |
sentience of some kind would be required to work out which 5% was |
| 52 |
wrong, and *not* to rely on the automated provisioning. |
| 53 |
|
| 54 |
And there are some authors on CPAN who I would institute a custom |
| 55 |
black hole stipulating that they should *only* contact gentoo about |
| 56 |
bugs and *never* upstream, because upstream have a marked track record |
| 57 |
of setting people who report their bugs on fire *due* to them being |
| 58 |
gentoo users. |
| 59 |
|
| 60 |
Its cool that there are lots of upstream who are capable and willing |
| 61 |
to deal with gentoo users directly. But the odds of a gentoo user |
| 62 |
assuming any upstream able /willing to be responsive and them getting |
| 63 |
unhelpful responses and the Gentoo user not realising they needed |
| 64 |
flame retardant clothing, makes me want to suggest a system wherein |
| 65 |
direct upstream contact by Gentoo users should be something decided |
| 66 |
upon based on the gentoo users technical competence. |
| 67 |
|
| 68 |
If for example, a Gentoo user is able to function at the level |
| 69 |
expected of a Gentoo developer, and are able to dig into the problem |
| 70 |
sufficient to isolate and comprehend the problem in a systems agnostic |
| 71 |
way, or at least express how and why Gentoo changes the behaviour of a |
| 72 |
system, then by all means, going straight to upstream should be fine, |
| 73 |
and they can ask for a revision bump once the problem is fixed, and if |
| 74 |
they're feeling generous, put a copy of their issue on bgo with |
| 75 |
possible solutions, because that is where gentoo users look first. |
| 76 |
|
| 77 |
But we shouldn't expect this level of performance from all users, and |
| 78 |
we should be capable and willing to try helping the less capable with |
| 79 |
reporting their issues to upstream. |
| 80 |
|
| 81 |
Some of this is just basic due dilligence, making sure the user has |
| 82 |
even reported the right information. |
| 83 |
|
| 84 |
If a user isn't able to provide information to gentoo sufficient that |
| 85 |
gentoo can even identify that a bug is in fact happening, they're just |
| 86 |
going to be irritating upstream, because upstream won't be able to |
| 87 |
easily plumb the gentoo specifics to make sure they haven't just done |
| 88 |
something dumb that gentoo has already put guards against that the |
| 89 |
user has unwittingly disabled. |
| 90 |
|
| 91 |
-- |
| 92 |
Kent |
| 93 |
|
| 94 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives