| 1 |
Hello Andreas, |
| 2 |
|
| 3 |
Friday, January 10, 2014, 9:20:17 PM, you wrote: |
| 4 |
|
| 5 |
>> As there are questions at to what we vote. |
| 6 |
|
| 7 |
>> ---------------------------------------------- |
| 8 |
|
| 9 |
> Realistically most people haven't even read your mails (too much bla). |
| 10 |
|
| 11 |
Please read the following and vote. |
| 12 |
|
| 13 |
What PortageQOS will be able to accumulate: |
| 14 |
|
| 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. |
| 17 |
|
| 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. |
| 21 |
|
| 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 |
| 24 |
|
| 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. |
| 27 |
|
| 28 |
* A formal esteem of portage quality |
| 29 |
PortageQ = (the number of successful ebuilds/the number of all ebuild attempts) |
| 30 |
|
| 31 |
Portage speed efficiency: |
| 32 |
Average time before build starts (or download starts) |
| 33 |
|
| 34 |
How many times portage fails itself. |
| 35 |
|
| 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) |
| 38 |
|
| 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. |
| 42 |
|
| 43 |
* Team efficiency esteem. The stats will tell what ebuilds are failing most often. |
| 44 |
|
| 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. |
| 49 |
|
| 50 |
It's not possible not to make mistakes. But it's possible to react on their consequences fast. |
| 51 |
|
| 52 |
* Knowledge what kernels are used by Gentoo users, how often they update their systems, what flags |
| 53 |
are used |
| 54 |
|
| 55 |
2nd turn goals: |
| 56 |
|
| 57 |
* to integrate forums.gentoo.org and bug tracker. People are offering great workarounds and solutions. But |
| 58 |
they're not known to the majority of Gentoo users. |
| 59 |
|
| 60 |
If a e-build fails - may be there is already a solution - and we can offer the solutions automatically from |
| 61 |
portage. Like: |
| 62 |
|
| 63 |
There might be some work-arounds on this problem: |
| 64 |
[Gentoo Forum - qt-core ebuild fails - SOLVED] |
| 65 |
htpp://forums.gentoo.org/..... |
| 66 |
|
| 67 |
There is a known bug on this ebuild: |
| 68 |
[Gentoo Bug - qt-core ebuild fails] |
| 69 |
htpp://forums.gentoo.org/..... |
| 70 |
|
| 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. |
| 74 |
|
| 75 |
The severity could be assigned automatically from package popularity and failure rate stats. |
| 76 |
|
| 77 |
These are the bricks that will be added in the initial design. |
| 78 |
|
| 79 |
-- |
| 80 |
Best regards, |
| 81 |
Igor mailto:lanthruster@×××××.com |
Archives