Gentoo Archives: gentoo-dev

From: Kent Fredric <kentfredric@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] minimalistic emerge
Date: Fri, 08 Aug 2014 21:33:36
In Reply to: Re: [gentoo-dev] minimalistic emerge by Igor
1 On 9 August 2014 08:52, Igor <lanthruster@×××××.com> wrote:
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 >
22 Yes. As I said, INSTALLATION metrics reporting is easy enough to do.
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.
28 So I greatly appreciate this utility.
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.
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.
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: , and one of the
41 reports it links to :
43 )
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.
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.
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.
59 If my firefox installation segv's, nothing is there watching for that to
60 file a report.
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.
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.
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.
76 For instance,
79 Those red lights told me that I had a bug on platforms where perl floating
80 point precision is reduced
82 In fact, *automated* factor analysis pin pointed the probable cause faster
83 than I ever could:
87 Just the main blockers are:
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.
99 --
100 Kent
102 *KENTNL* -


Subject Author
Re: [gentoo-dev] minimalistic emerge Ian Stakenvicius <axs@g.o>
Re: [gentoo-dev] minimalistic emerge Igor <lanthruster@×××××.com>