| 1 |
On 10 August 2014 07:22, Jeroen Roovers <jer@g.o> wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> Example 2: Mr. I.B. User configured his system with CFLAGS=-fomg-faster |
| 5 |
> and now it generates a ton of build failures. All of these should go |
| 6 |
> to /dev/null, but there we are running an automated service that cannot |
| 7 |
> be taught how to distinguish between genuine bug reports and PEBKAC. |
| 8 |
> |
| 9 |
> The problem: How do you propose to filter out all the junk and promote |
| 10 |
> genuine issues to "bug reports"? |
| 11 |
> |
| 12 |
> Both examples should make clear why we have a bug tracker and not an |
| 13 |
> automated build failure reporting facility - it works rather well and |
| 14 |
> it stops dead a lot of spam and bad reports. |
| 15 |
|
| 16 |
|
| 17 |
^ In practice this doesn't prove to be an issue for CPAN, *because* it uses |
| 18 |
a seperate channel from the bug reports. |
| 19 |
|
| 20 |
The isolation means you can either choose to delve into the metrics, or |
| 21 |
simply ignore them, they don't affect your workflow unless you want them to. |
| 22 |
|
| 23 |
Users with misconfigured systems do occur from time to time, and you just |
| 24 |
get a knack for knowing which reports are reports you can fix, and which |
| 25 |
you just leave to rot. |
| 26 |
|
| 27 |
And there's no *onus* on you to fix anything, because its only an automated |
| 28 |
report, its intended to give you installation context *if* and *when* you |
| 29 |
want it, as opposed to interrupting you and demanding attention. |
| 30 |
|
| 31 |
For instance: http://matrix.cpantesters.org/?dist=IO+1.25 |
| 32 |
|
| 33 |
This shows the CPAN version of IO can't be installed on >5.18, on windows |
| 34 |
and a few darwin boxes. |
| 35 |
|
| 36 |
The maintainer of IO doesn't *HAVE* to do anything here, its just |
| 37 |
information they can go swimming for if they want to. |
| 38 |
|
| 39 |
=~ Its up to the maintainer if they want to respond to this information or |
| 40 |
not. |
| 41 |
|
| 42 |
If a user desires a response, they still have to file a bug report. |
| 43 |
|
| 44 |
|
| 45 |
Though it does prove useful as a user filing a bug report to be able to see |
| 46 |
all the other failure reports and know "Hey, its not just me, this is a |
| 47 |
real problem and I'm not making it up", and be able to link to a bunch of |
| 48 |
them, which cross comparison quickly reveals common elements to investigate |
| 49 |
as probable failing points. |
| 50 |
|
| 51 |
But I'm very much in agreement that such as system should NEVER be attached |
| 52 |
as a pump handle to bugzilla itself. |
| 53 |
|
| 54 |
|
| 55 |
-- |
| 56 |
Kent |
| 57 |
|
| 58 |
*KENTNL* - https://metacpan.org/author/KENTNL |
Archives