1 |
On 9 August 2014 08:52, Igor <lanthruster@×××××.com> wrote: |
2 |
|
3 |
> Hello Kent, |
4 |
> |
5 |
> Friday, August 8, 2014, 9:29:54 PM, you wrote: |
6 |
> |
7 |
> But it's possible to fix many problems even now! |
8 |
> |
9 |
> What would you tell if something VERY simple is implemented like - |
10 |
> reporting |
11 |
> every emerge failed due to slot conflict back home with details for |
12 |
> inspection? |
13 |
> |
14 |
> |
15 |
> |
16 |
> |
17 |
> *-- Best regards, Igor * |
18 |
> mailto:lanthruster@×××××.com <lanthruster@×××××.com> |
19 |
> |
20 |
|
21 |
|
22 |
Yes. As I said, INSTALLATION metrics reporting is easy enough to do. |
23 |
|
24 |
I use those sorts of tools EXTENSIVELY with the CPAN platform, and I have |
25 |
valuable reports on what failed, what the interacting components were, and |
26 |
what systems the failures and passes occur on. |
27 |
|
28 |
So I greatly appreciate this utility. |
29 |
|
30 |
Automated bug reports however prove to be a waste of time, a lot of |
31 |
failures are in fact entirely spurious as a result of user error. |
32 |
|
33 |
So a metrics system that simply aggregates automated reports from end users |
34 |
that is observed as a side channel to bugs, proves more beneficial in |
35 |
reality. |
36 |
|
37 |
Usually all maintainers need here is a daily or even weekly digest mail |
38 |
summarising all the packages they're involved with, with their failure |
39 |
summaries, with links to the failures. ( For example, here is one of the |
40 |
report digests I received: http://i.imgur.com/WISqv15.png , and one of the |
41 |
reports it links to : |
42 |
http://www.cpantesters.org/cpan/report/ed7a4d9f-6bf3-1014-93f0-e557a945bbef |
43 |
) |
44 |
|
45 |
And for such, you don't need to apply rate limiting, because multiple |
46 |
reports from a single individual prove to be entirely inconsequential, as |
47 |
you're not forced to deal with them like normal bugs, but are simply out of |
48 |
band feedback you can read when you have the time. |
49 |
|
50 |
And you can then make sense of the content of that report using your inside |
51 |
expertise and potentially file a relevant bug report based on extracted |
52 |
information, or use context of that bug report to request more context from |
53 |
its submitter. |
54 |
|
55 |
But the point remains that this techology is _ONLY_ effective for install |
56 |
time metrics, and is utterly useless for tracking any kinds of failures |
57 |
that emanate from the *USE* of software. |
58 |
|
59 |
If my firefox installation segv's, nothing is there watching for that to |
60 |
file a report. |
61 |
|
62 |
If firefox does something odd like renders characters incorrectly due to |
63 |
some bug in GPU drivers ( actual issue I had once ), nothing will be |
64 |
capable of detecting and reporting that. |
65 |
|
66 |
Those things are still "bugs" and are still "bugs in packages" and still |
67 |
"bugs in packages that can be resolved by changing dependencies", but are |
68 |
however completely impossible to test for in advance of them happening as |
69 |
part of the installation toolchain. |
70 |
|
71 |
But I'm still very much on board with "have the statistics system". I use |
72 |
it extensively, as I've said, and it is very much one of the best tools I |
73 |
have for solving problems. ( the very distribution of the problems can |
74 |
itself be used to isolate bugs. |
75 |
|
76 |
For instance, |
77 |
http://matrix.cpantesters.org/?dist=Color-Swatch-ASE-Reader%200.001000 |
78 |
|
79 |
Those red lights told me that I had a bug on platforms where perl floating |
80 |
point precision is reduced |
81 |
|
82 |
In fact, *automated* factor analysis pin pointed the probable cause faster |
83 |
than I ever could: |
84 |
|
85 |
http://analysis.cpantesters.org/solved?distv=Color-Swatch-ASE-Reader-0.001000 |
86 |
|
87 |
Just the main blockers are: |
88 |
|
89 |
- Somebody has to implement this technology |
90 |
- That requires time and effort |
91 |
- People have to be convinced of its value |
92 |
- Integration must happen at some level somehow somewhere in the portage |
93 |
toolchain(s) |
94 |
- People must opt in to this technology in order for the reports to happen |
95 |
- And only then can this start to deliver meaningful results. |
96 |
|
97 |
|
98 |
|
99 |
-- |
100 |
Kent |
101 |
|
102 |
*KENTNL* - https://metacpan.org/author/KENTNL |