Gentoo Archives: gentoo-dev

From: Igor <lanthruster@×××××.com>
To: "Andreas K. Huettel" <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Question, Portage QOS v2
Date: Fri, 10 Jan 2014 17:39:40
In Reply to: Re: [gentoo-dev] Question, Portage QOS v2 by "Andreas K. Huettel"
1 Hello Andreas,
3 Friday, January 10, 2014, 9:20:17 PM, you wrote:
5 >> As there are questions at to what we vote.
7 >> ----------------------------------------------
9 > Realistically most people haven't even read your mails (too much bla).
11 Please read the following and vote.
13 What PortageQOS will be able to accumulate:
15 * Knowledge of the number of Gentoo distros installed world wide - knowing the trend how many users choose
16 Gentoo and where Gentoo is really going down|up|stands still.
18 You can then try different features and see how a feature is met - if the number of systems increase
19 then this feature is probably useful. It's a strategical job, somebody at the very top of the project should
20 analyze databases and make conclusions.
22 * Knowledge of the ebuild popularity - what ebuilds are popular and what are not - what ebuild to give an extra focus
23 and what ebuild could wait
25 * Knowledge of ebuild quality. If some ebuilds fail on many systems - something is wrong and ebuild and may be portage
26 need fixing. It's especially useful to make sure that all ebuilds have correct dependencies, missing dependencies, etc.
28 * A formal esteem of portage quality
29 PortageQ = (the number of successful ebuilds/the number of all ebuild attempts)
31 Portage speed efficiency:
32 Average time before build starts (or download starts)
34 How many times portage fails itself.
36 * Immediate problem detection. If the number of PortageQ went down last day - there is some problem.
37 (then you go to ebuild stats and see what is failing)
39 * Reducing load on bugtracker folks - the build problems will be detected automatically and solved according
40 to their importance. There will be no need to supply bug tracker with ebuild logs and emerge --info if
41 somebody wants to report a problem.
43 * Team efficiency esteem. The stats will tell what ebuilds are failing most often.
45 * Team automated info. When failure rate of a certain ebuild increase the maintainer is automatically
46 informed and he can login in web-interface and see details how exactly ebuild failed.
47 The same for the portage itself. Next day a maintainer could push a new ebuild in the portage and the
48 problem might be solved.
50 It's not possible not to make mistakes. But it's possible to react on their consequences fast.
52 * Knowledge what kernels are used by Gentoo users, how often they update their systems, what flags
53 are used
55 2nd turn goals:
57 * to integrate and bug tracker. People are offering great workarounds and solutions. But
58 they're not known to the majority of Gentoo users.
60 If a e-build fails - may be there is already a solution - and we can offer the solutions automatically from
61 portage. Like:
63 There might be some work-arounds on this problem:
64 [Gentoo Forum - qt-core ebuild fails - SOLVED]
65 htpp://
67 There is a known bug on this ebuild:
68 [Gentoo Bug - qt-core ebuild fails]
69 htpp://
71 * to make Bug Tracker almost unmanned. We can use gathered infromation on failed e-builds to
72 create bugs in Bug Tracker automatically and automatically set priorities according to the
73 severity.
75 The severity could be assigned automatically from package popularity and failure rate stats.
77 These are the bricks that will be added in the initial design.
79 --
80 Best regards,
81 Igor mailto:lanthruster@×××××.com