From gentoo-dev Fri Aug 08 20:52:17 2014 From: Igor Date: Fri, 08 Aug 2014 20:52:17 +0000 To: gentoo-dev Subject: Re: [gentoo-dev] minimalistic emerge Message-Id: <53e53883.a5e0980a.6062.2fd6 () mx ! google ! com> X-MARC-Message: https://marc.info/?l=gentoo-dev&m=140753114726993 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------12517918626BD8E82" ------------12517918626BD8E82 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Kent, Friday, August 8, 2014, 9:29:54 PM, you wrote: But it's possible to fix many problems even now! What would you tell if something VERY simple is implemented like - reportin= g=20 every emerge failed due to slot conflict back home with details for inspect= ion? If maintainers had that kind of data then they could learn from the wild. I= don't know what=20 they would learn but I know it would be a very useful experience that might= jump start=20 evolution - useful updates to emerge and other tools. Almost every system d= esigned by nature has=20 feedback functions. It's the safe update - it will work even if not optimal= from the start or even if it's not clear what it will help to learn. The quality of ebuild= s would improve too. And from the useful life database new tools could evolve like - bug reporti= ng automatization a=20 whole new world of tool. http://db.gentoo.org/report/ System: System name=20 Arch:=20 Package emerged: .... Environment: .... Dependency graph: .... -> ... -> ... Fail message: * 3 reports per day are accepted from one single IP * no dups=20 http://db.gentoo.org/stats/ - SlickGrid stats Arch Package How many times Failed Fail message=20 Click on Package -> Dependency Graph=20 If GENTOO had everything emerging from any state (goal unattainable but des= irable) that=20 would be a great advantage for the users. That feel of a lean mean machine = that saves time - it's=20 tasty - new fans warranted. On 9 August 2014 04:58, Igor wrote: Maintainers have no feedback from their ebuilds, they all do their best but= there are no tools=20 to formalize their work. No compass. They have no access to user=20 space where the packages are installed, unaware how users are using their e= builds. It's the design=20 failure that hunts Gentoo from the start - no global intellectual bug track= ing system. Doing not mistakes - not possible, the automated tracking sub-systems should be there but... w= e are where we are.=20 Some of that is doable, ie: we could have installation metrics systems like= CPAN has a testers network with a matrix showing where a given thing is fa= iling : http://matrix.cpantesters.org/?dist=3DCPAN-Meta-Requirements%202.126 But its a lot of work investment to support. And beyond "it installs" and "its tests pass", its piratically infeasible t= o track software failing beyond there. And some of the reasons we have dependency declarations are to avoid proble= ms that will ONLY be seen at runtime and WONT be seen during installation o= r testing. ( Usually because the problem was found before there were tests = for it ) For that, only manual feedback systems, such as our present bugzilla, are a= dequate.=20 --=20 Kent=20 KENTNL - https://metacpan.org/author/KENTNL --=20 Best regards, Igor mailto:lanthruster@gmail.com ------------12517918626BD8E82 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re: [gentoo-dev] minimalistic emerge Hello Kent,

Friday, August 8, 2014, 9:29:54 PM, you wrote:

But it's possible to fix many problems even now!

What would you tell if something VERY simple is implemented like - reportin= g 
every emerge failed due to slot conflict back home with details for inspect= ion?

If maintainers had that kind of data then they could learn from the wild. I= don't know what 
they would learn but I know it would be a very useful experience that might= jump start 
evolution - useful updates to emerge and other tools. Almost every system d= esigned by nature has 
feedback functions. It's the safe update - it will work even if not optimal= from the start
or even if it's not clear what it will help to learn. The quality of ebuild= s would improve too.

And from the useful life database new tools could evolve like - bug reporti= ng automatization a 
whole new world of tool.

http://db.gentoo.org/report/

    =  System: System name 
       Arch: 
Package emerged: ....
Environment: ....
Dependency graph: .... -> ... -> ...
Fail message:

* 3 reports per day are accepted from one single IP
* no dups 

http://db.gentoo.org/stats/

- SlickGrid st= ats

Arch Package How many times Failed Fail message 

Click on Package -> Dependency Graph 

If GENTOO had everything emerging from any state (goal unattainable but des= irable) that 
would be a great advantage for the users. That feel of a lean mean machine = that saves time - it's 
tasty - new fans warranted.

On 9 August 20= 14 04:58, Igor <lanthruster@gmail.com> wrote:
Maintainers have no feedback from their ebuilds, they all do their best but= there are no tools 
to formalize their work. No compass. They have no access to user 
space where the packages are installed, unaware how users are using their e= builds. It's the design 
failure that hunts Gentoo from the start - no global intellectual bug track= ing system. Doing not mistakes
- not possible, the automated tracking sub-systems should be there but... w= e are where we are. 
Some of that is doable, ie: we could have installation metrics systems like= CPAN has a testers network with a matrix showing where a given thing is fa= iling : http://matrix.cpantesters.org/?dist=3DCPAN-Meta-Requirements%202.126<= /a>

But its a lot = of work investment to support.

And beyond "it installs" and "its tests pass", its piratically infeasible t= o track software failing beyond there.

And some of the reasons we have dependency declarations are to avoid proble= ms that will ONLY be seen at runtime and WONT be seen during installation o= r testing. ( Usually because the problem was found before there were tests = for it )

For that, only manual feedback systems, such as our present bugzilla, are a= dequate. 


-- 
Kent 

KENTNL - https:/= /metacpan.org/author/KENTNL




-- 
Best regards,
 Igor                   &= nbsp;