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 |
> |