1 |
Hello Alec, |
2 |
|
3 |
Thursday, January 9, 2014, 12:12:18 PM, you wrote: |
4 |
|
5 |
|
6 |
On Wed, Jan 8, 2014 at 11:24 PM, LTHR <lanthruster@×××××.com> wrote: |
7 |
Hi All, |
8 |
|
9 |
|
10 |
I want to start off by discussing your premise, before embarking on the overall goals. |
11 |
|
12 |
You wrote: |
13 |
"I'm with Gentoo for many years. For various reasons many techs were not implemented and now Gentoo is in a kind of stagnation. But we can give Gentoo a new birth with relatively little efforts and bring the distro to the whole new level. " |
14 |
|
15 |
I don't actually believe your premise of stagnation. But I can put aside my disagreement for now. |
16 |
|
17 |
|
18 |
True. There is no data to tell what happens with Gentoo (to give that data is one of the goals of the |
19 |
project). We only have some formal esteems from unreliable sources. |
20 |
|
21 |
According to distro watch: |
22 |
|
23 |
http://web.archive.org/web/20130701000000*/http://distrowatch.com/dwres.php?resource=popularity |
24 |
|
25 |
In February 2012, Gentoo distro was in 19th place. |
26 |
In December 2012, Gentoo went to 22nd place. |
27 |
In December 2013, Gentoo is down to 32nd place |
28 |
|
29 |
According to Linux Counter |
30 |
http://web.archive.org/web/20120101000000*/http://linuxcounter.net/distributions/stats.html |
31 |
|
32 |
In January 2012, Gentoo distro had 5.32% |
33 |
In January 2012, Gentoo had 4.04% |
34 |
In November 2013, Gentoo had 4,21% |
35 |
|
36 |
And from my experience of Gentoo forums, gentoo.wiki - I vote for Gentoo at least not gaining new users. |
37 |
If in several years the number of users is not increased - we can tell about stagnation. |
38 |
|
39 |
Why new users are not with Gentoo and how to get them - good question, let's find out! |
40 |
|
41 |
|
42 |
Lets talk about how the overall goal of 'bringing the distro to a whole new level' and how 'Portage QoS' will help us get there. I don't think you covered these points well in your post (I will talk about the goals more below...) |
43 |
|
44 |
|
45 |
I'll re-phrase the goals. |
46 |
|
47 |
It's all not very well thought after at this stage but immediate goals are like this: |
48 |
|
49 |
|
50 |
* Knowledge of the number of Gentoo distros installed world wide - knowing the trend how many users choose |
51 |
Gentoo and where Gentoo is really going down|up|stands still. |
52 |
|
53 |
You can then try different features and see how a feature is met - if the number of systems increase |
54 |
then this feature is probably useful. It's a strategical job, somebody at the very top of the project should |
55 |
analyze databases and make conclusions. |
56 |
|
57 |
* Knowledge of the ebuild popularity - what ebuilds are popular and what are not - what ebuild to give an extra focus |
58 |
and what ebuild could wait |
59 |
|
60 |
* Knowledge of ebuild quality. If some ebuilds fail on many systems - something is wrong and ebuild and may be portage |
61 |
need fixing. It's especially useful to make sure that all ebuilds have correct dependencies, missing dependencies, etc. |
62 |
|
63 |
* A formal esteem of portage quality |
64 |
PortageQ = (the number of successful ebuilds/the number of all ebuild attempts) |
65 |
|
66 |
Portage speed efficiency: |
67 |
Average time before build starts (or download starts) |
68 |
|
69 |
How many times portage fails itself. |
70 |
|
71 |
* Immediate problem detection. If the number of PortageQ went down last day - there is some problem. |
72 |
(then you go to ebuild stats and see what is failing) |
73 |
|
74 |
* Reducing load on bugtracker folks - the build problems will be detected automatically and solved according |
75 |
to their importance. There will be no need to supply bug tracker with ebuild logs and emerge --info if |
76 |
somebody wants to report a problem. |
77 |
|
78 |
* Team efficiency esteem. The stats will tell what ebuilds are failing most often. |
79 |
|
80 |
* Team automated info. When failure rate of a certain ebuild increase the maintainer is automatically |
81 |
informed and he can login in web-interface and see details how exactly ebuild failed. |
82 |
The same for the portage itself. Next day a maintainer could push a new ebuild in the portage and the |
83 |
problem might be solved. |
84 |
|
85 |
It's not possible not to make mistakes. But it's possible to react on their consequences fast. |
86 |
|
87 |
* Knowledge what kernels are used by Gentoo users, how often they update their systems, what flags |
88 |
are used |
89 |
|
90 |
2nd turn goals: |
91 |
|
92 |
* to integrate forums.gentoo.org and bug tracker. People are offering great workarounds and solutions. But |
93 |
they're not known to the majority of Gentoo users. |
94 |
|
95 |
If a e-build fails - may be there is already a solution - and we can offer the solutions automatically from |
96 |
portage. Like: |
97 |
|
98 |
There might be some work-arounds on this problem: |
99 |
[Gentoo Forum - qt-core ebuild fails - SOLVED] |
100 |
htpp://forums.gentoo.org/..... |
101 |
|
102 |
There is a known bug on this ebuild: |
103 |
[Gentoo Bug - qt-core ebuild fails] |
104 |
htpp://forums.gentoo.org/..... |
105 |
|
106 |
* to make Bug Tracker almost unmanned. We can use gathered infromation on failed e-builds to |
107 |
create bugs in Bug Tracker automatically and automatically set priorities according to the |
108 |
severity. |
109 |
|
110 |
The severity could be assigned automatically from package popularity and failure rate stats. |
111 |
|
112 |
The users with the problems could receive e-mail automatically to follow up the quick arounds |
113 |
and solutions. |
114 |
|
115 |
No need to change bug-tracker version, you just need a robot who would maintain bug-tracker |
116 |
analyazing PortageQOS databases. |
117 |
|
118 |
|
119 |
I'm sure there could be more applications of the system. |
120 |
|
121 |
|
122 |
|
123 |
Back to the premise of bringing the distro to a whole new level. Some of the items above I think have merits on their own, but they still don't guide me to your ultimate goal. You outlined some of what I presume to be defects in Gentoo today. |
124 |
|
125 |
|
126 |
It's hard to see more goals at this stage. It's like when you're building a hammer to set a nail and |
127 |
then when you have it you discover that you may use it to pull a nail too. It's for the future developers |
128 |
to decide. |
129 |
|
130 |
Knowledge: So I think in general I agree, insofar as more information can be helpful in making decisions. I think you should take note that there are at least 4-5 'gentoo stats' projects that have been tried and my understanding is that none of them are in operation today. |
131 |
|
132 |
True, one of the reasons - the whole system planning shouldn't be apart from Gentoo developers. |
133 |
|
134 |
I could write the whole system on paper, with tools, soft used and the system design not narrowing to the table structures. |
135 |
Then everyone could contribute his experience to it or see a problem at design time. |
136 |
|
137 |
I know how to design the system to make handling significant load. It has a good chance |
138 |
to work fast and to be scalable. |
139 |
|
140 |
|
141 |
With the design approved by others, programming is easy. |
142 |
|
143 |
It's not going to be very complex. |
144 |
I estimate the whole system as 10 000 - 15 000 lines max in different languages. The most difficult part would |
145 |
be to make it scalable and fast as we don't know how many ebuilds are done world wide per second and we |
146 |
have to be prepared to hot-plug hardware at any time not redesigning the system. And the system shouldn't get |
147 |
overloaded/loose functionality. |
148 |
|
149 |
|
150 |
|
151 |
Package blocks that portage does not resolve automatically |
152 |
Slot conflicts that portage does not resolve automatically |
153 |
Compile failures |
154 |
...What else? |
155 |
|
156 |
So part of the Portage QoS system is that users will submit their failures and Portage QoS will serve as a knowledge base of known issues. To me, that is still a pretty bad User Experience. Can't we just get portage to handle these issues transparently, as per http://forums.gentoo.org/viewtopic-t-977936.html |
157 |
|
158 |
|
159 |
|
160 |
|
161 |
If we ask users about questions they don't know answers to it will result in users loss. But it's totally |
162 |
out of my expertise if the portage interaction is GOOD |
163 |
|
164 |
Users are not doing anything usual than they do right now. The reports are sent transparently by |
165 |
portage to the PorageQOS load balancer and the suggestions are received. |
166 |
|
167 |
|
168 |
|
169 |
Just a brief question - does anyone know how many ebuilds are assembled world |
170 |
wide each second? |
171 |
|
172 |
I bet you more apks are installed per second ;) |
173 |
|
174 |
-A |
175 |
|
176 |
-- |
177 |
Best regards, |
178 |
LTHR mailto:lanthruster@×××××.com |
179 |
|
180 |
|
181 |
|
182 |
|
183 |
-- |
184 |
Best regards, |
185 |
Igor mailto:lanthruster@×××××.com |