[gentoo-dev] Question, Portage QOS v2

[gentoo-dev] Question, Portage QOS v2

[Igor]

Hello All,

As there are questions at to what we vote.

----------------------------------------------

Thank you for all our feedback!

In project like that I can't rush to programming it without
everyone's approval. This part of the project should have been
implemented with the first portage version by it's creator. But as
I'm not this person I'll need the expertise of the whole community.

Let's agree on following - I'll design the system in details on paper
but no code will be produced at this stage.

When it's ready (~ 1.5 months) I'll get back here and share the design
sketches with you.

Then we all review it again everyone could contribute it's own view
and part and help to avoid some design problems if there are.

I need an agreement on this stage from the list.

If you consider PortageQOS is not necessary please vote NO.
If you consider PortageQOS might have a chance and it depends on
implementation say YES.


Please vote.


If NO there is no need to spend time even on sketches.
If YES - there will be a system design ready and we could at least
imagine how it might work as a whole and benefits it might bring.



PS
No way PortageQOS will work without uniform agreement. That thing
was missing from portage design from the start and now with the legacy
it's either everyone is willing to give it a try or none. I don't want
to push somebody to something he doesn't see purpose for. There are
people here who spent lots of time on the project and it might be left
as is if they don't want any change.

-- 
Best regards,
 Igor                          mailto:lanthruster@gmail.com

Re: [gentoo-dev] Question, Portage QOS v2

[Andreas K. Huettel]

Am Freitag 10 Januar 2014, 21:18:58 schrieb Igor:
> Hello All,
> 
> As there are questions at to what we vote.
> 
> ----------------------------------------------

Realistically most people haven't even read your mails (too much bla).

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

Re: [gentoo-dev] Question, Portage QOS v2

[Igor]

Hello Andreas,

Friday, January 10, 2014, 9:20:17 PM, you wrote:

>> As there are questions at to what we vote.

>> ----------------------------------------------

> Realistically most people haven't even read your mails (too much bla).

Please read the following and vote.

What PortageQOS will be able to accumulate: 

* Knowledge of the number of Gentoo distros installed world wide - knowing the trend how many users choose 
Gentoo and where Gentoo is really going down|up|stands still. 

You can then try different features and see how a feature is met - if the number of systems increase 
then this feature is probably useful. It's a strategical job, somebody at the very top of the project should 
analyze databases and make conclusions. 

* Knowledge of the ebuild popularity - what ebuilds are popular and what are not - what ebuild to give an extra focus 
and what ebuild could wait

* Knowledge of ebuild quality. If some ebuilds fail on many systems - something is wrong and ebuild and may be portage 
need fixing. It's especially useful to make sure that all ebuilds have correct dependencies, missing dependencies, etc.

* A formal esteem of portage quality 
PortageQ = (the number of successful ebuilds/the number of all ebuild attempts)

Portage speed efficiency: 
Average time before build starts (or download starts)

How many times portage fails itself. 

* Immediate problem detection. If the number of PortageQ went down last day - there is some problem. 
(then you go to ebuild stats and see what is failing)

* Reducing load on bugtracker folks - the build problems will be detected automatically and solved according 
to their importance. There will be no need to supply bug tracker with ebuild logs and emerge --info if 
somebody wants to report a problem. 

* Team efficiency esteem. The stats will tell what ebuilds are failing most often. 

* Team automated info. When failure rate of a certain ebuild increase the maintainer is automatically 
informed and he can login in web-interface and see details how exactly ebuild failed. 
The same for the portage itself. Next day a maintainer could push a new ebuild in the portage and the 
problem might be solved.

It's not possible not to make mistakes. But it's possible to react on their consequences fast. 

* Knowledge what kernels are used by Gentoo users, how often they update their systems, what flags 
are used 

2nd turn goals: 

* to integrate forums.gentoo.org and bug tracker. People are offering great workarounds and solutions. But 
they're not known to the majority of Gentoo users. 

If a e-build fails - may be there is already a solution - and we can offer the solutions automatically from 
portage. Like:

There might be some work-arounds on this problem: 
[Gentoo Forum - qt-core ebuild fails - SOLVED] 
htpp://forums.gentoo.org/..... 

There is a known bug on this ebuild: 
[Gentoo Bug - qt-core ebuild fails] 
htpp://forums.gentoo.org/..... 

* to make Bug Tracker almost unmanned. We can use gathered infromation on failed e-builds to 
create bugs in Bug Tracker automatically and automatically set priorities according to the 
severity. 

The severity could be assigned automatically from package popularity and failure rate stats.

These are the bricks that will be added in the initial design.

-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

Re: [gentoo-dev] Question, Portage QOS v2

[Igor]

Hello Andreas,

Friday, January 10, 2014, 9:20:17 PM, you wrote:


> Realistically most people haven't even read your mails (too much bla).

And one more goal - without PortageQOS you're forever stuck with
the legacy portage design.

If the team ever decides to change Portage you'll need feedback
on how the new portage works to patch it quickly in case there are
troubles. It's too risky to touch portage right now. Everyone
understands that this is a kamikaze job. 

-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

Re: [gentoo-dev] Question, Portage QOS v2

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On Fri, 10 Jan 2014 21:46:18 +0400
Igor <lanthruster@gmail.com> wrote:
> And one more goal - without PortageQOS you're forever stuck with
> the legacy portage design.
> 
> If the team ever decides to change Portage you'll need feedback
> on how the new portage works to patch it quickly in case there are
> troubles. It's too risky to touch portage right now. Everyone
> understands that this is a kamikaze job. 

Uh, no. We already know lots of things that are wrong with the Portage
design. We also know how to fix those things. Neither of those is the
sticking point.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]