Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Portage QOS
Date: Thu, 09 Jan 2014 08:12:26
Message-Id: CAAr7Pr9a_BRZji8LTJb7rE53ASgyA4nP2ysVGkr+5m5JRjnYDw@mail.gmail.com
In Reply to: [gentoo-dev] Portage QOS by LTHR
1 On Wed, Jan 8, 2014 at 11:24 PM, LTHR <lanthruster@×××××.com> wrote:
2
3 > Hi All,
4 >
5 >
6 I want to start off by discussing your premise, before embarking on the
7 overall goals.
8
9 You wrote:
10 "I'm with Gentoo for many years. For various reasons many techs were not
11 implemented and now Gentoo is in a kind of stagnation. But we can give
12 Gentoo a new birth with relatively little efforts and bring the distro to
13 the whole new level. "
14
15 I don't actually believe your premise of stagnation. But I can put aside my
16 disagreement for now. Lets talk about how the overall goal of 'bringing the
17 distro to a whole new level' and how 'Portage QoS' will help us get there.
18 I don't think you covered these points well in your post (I will talk about
19 the goals more below...)
20
21
22 > What do you think about implementing this:
23 >
24 > http://forums.gentoo.org/viewtopic.php?p=7477494
25 >
26 I've system design in my head and could write it down with the
27 > implementation details.
28 > Then may be we could all review it and get to something we all agree upon
29 > then I could
30 > try getting a team and implement it.
31 >
32
33 Later in your post you wrote about the goals for Porage QoS.
34
35 Time we spare time for everyone - users, developers, maintainers.
36 Quality in 3-5 years we improve GENTOO in a way it will be in top10
37 distros, the users will be happy
38 Automatization no time to waste to improve Gentoo for the community,
39 everyone with GENTOO is part of GENTOO working for GENTOO
40 Bug Tracking no more we spare resources deployed in the bug tracking
41 system. It will exist. But's it's will be extended with robotic help from
42 Portage QOS
43 Knowledge we will know exactly who, how in what way GENTOO is used and we
44 will create a system for USERS not vice-versa
45 Order we will know exactly where to go next and what to do next what focus
46 on next
47 Integrity all GENTOO users will be able to participate in project. No
48 matter what experience they have. We will utilize help of a great number of
49 supporters.
50
51 Time: Portage QoS will save everyone time. I can actually believe this in
52 an ideal world where developers built automation around a system like
53 Portage QoS. Ironically I think tool development for *developers* is an
54 area that we are terrible at. Perhaps Portage QoS will have an awesome
55 easy-to-use API that makes tool writing a breeze, I don't really know. I
56 don't think blaming the portage API is necessarily the key to 'all our
57 tools are terrible' though.
58
59 Quality: Portage QoS will improve 'quality'. Again though, we don't really
60 measure quality in any quantitative way. If we switch to automated
61 reporting of failures, quality will actually go down, if we count quality
62 as 'reports of problems' because now reports are automated, rather than
63 manual. I think the big fear here is that many teams are already
64 understaffed and the automated system will quickly drown them. I imagine
65 Portage QoS could solve the 'drowning' problem, but i haven't see many
66 systems handle it well.
67
68 Bug tracking: Spend less resources on bug tracking. I think there is a lot
69 of missed opportunity for bugs automation. The sad fact is that infra is
70 terrible in areas like this, because the bug system is very opaque for
71 non-infra folks and the infra folks involved are not interested / don't
72 have time to implement the automation. So I will nominally agree here (even
73 if the automation isn't necessarily Portage QoS;e.g. we have discussed
74 automated bug assignment for *years*)
75
76 Knowledge: So I think in general I agree, insofar as more information can
77 be helpful in making decisions. I think you should take note that there are
78 at least 4-5 'gentoo stats' projects that have been tried and my
79 understanding is that none of them are in operation today.
80
81 Future Planning (you wrote: Order): I think this segment sort of
82 illustrates a misunderstanding of the Gentoo project as it is today. I
83 don't think developers are necessarily 'confused at how Gentoo is used' or
84 'do not know what to work on next.' I think developers work on whatever
85 they find interesting (that is what I do anyway ;p)
86
87 Back to the premise of bringing the distro to a whole new level. Some of
88 the items above I think have merits on their own, but they still don't
89 guide me to your ultimate goal. You outlined some of what I presume to be
90 defects in Gentoo today.
91
92 Package blocks that portage does not resolve automatically
93 Slot conflicts that portage does not resolve automatically
94 Compile failures
95 ...What else?
96
97 So part of the Portage QoS system is that users will submit their failures
98 and Portage QoS will serve as a knowledge base of known issues. To me, that
99 is still a pretty bad User Experience. Can't we just get portage to handle
100 these issues transparently, as per
101 http://forums.gentoo.org/viewtopic-t-977936.html
102
103 Just a brief question - does anyone know how many ebuilds are assembled
104 > world
105 > wide each second?
106 >
107
108 I bet you more apks are installed per second ;)
109
110 -A
111
112
113 >
114 >
115 > *-- Best regards, LTHR *
116 > mailto:lanthruster@×××××.com <lanthruster@×××××.com>
117 >

Replies

Subject Author
Re: [gentoo-dev] Portage QOS Igor <lanthruster@×××××.com>