[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev] minimalistic emerge
From: Igor <lanthruster () gmail ! com>
Date: 2014-08-08 20:52:17
Message-ID: 53e53883.a5e0980a.6062.2fd6 () mx ! google ! com
[Download RAW message or body]
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 - \
reporting every emerge failed due to slot conflict back home with details \
for inspection?
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 designed 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 \
ebuilds would improve too.
And from the useful life database new tools could evolve like - bug \
reporting 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 stats
Arch Package How many times Failed Fail message
Click on Package -> Dependency Graph
If GENTOO had everything emerging from any state (goal unattainable but \
desirable) 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 2014 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 ebuilds. It's the design failure that hunts Gentoo from \
the start - no global intellectual bug tracking system. \
Doing not mistakes
- not possible, the automated tracking sub-systems should be there but... \
we 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 failing : \
http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126
But its a lot of work investment to support.
And beyond "it installs" and "its tests pass", its piratically infeasible \
to track software failing beyond there.
And some of the reasons we have dependency declarations are to avoid \
problems that will ONLY be seen at runtime and WONT be seen during \
installation or 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 \
adequate.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
--
Best regards,
Igor mailto:lanthruster@gmail.com
[Attachment #3 (text/html)]
<html><head><title>Re: [gentoo-dev] minimalistic emerge</title>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 10pt;">Hello Kent,<br>
<br>
Friday, August 8, 2014, 9:29:54 PM, you wrote:<br>
<br>
But it's possible to fix many problems even now!<br>
<br>
What would you tell if something VERY simple is implemented like - \
reporting <br> every emerge failed due to slot conflict back home with \
details for inspection?<br> <br>
If maintainers had that kind of data then they could learn from the wild. I \
don't know what <br> they would learn but I know it would be a very \
useful experience that might jump start <br> evolution - useful \
updates to emerge and other tools. Almost every system designed by nature \
has <br> feedback functions. It's the safe update - it will work even \
if not optimal from the start<br> or even if it's not clear what it will \
help to learn. The quality of ebuilds would improve too.<br> <br>
And from the useful life database new tools could evolve like - bug \
reporting automatization a <br> whole new world of tool.<br>
<br>
</span><a style=" font-family:'Courier New'; font-size: 10pt;" \
href="http://db.gentoo.org/report/">http://db.gentoo.org/report/</a><br> \
<br> <span style=" font-family:'Courier New'; font-size: 10pt;"> \
System: System name <br> \
Arch: <br> Package emerged: ....<br>
Environment: ....<br>
Dependency graph: .... -> ... -> ...<br>
Fail message:<br>
<br>
* 3 reports per day are accepted from one single IP<br>
* no dups <br>
<br>
</span><a style=" font-family:'Courier New'; font-size: 10pt;" \
href="http://db.gentoo.org/stats/">http://db.gentoo.org/stats/</a><br> <br>
<span style=" font-family:'Courier New'; font-size: 10pt;">- SlickGrid \
stats<br> <br>
Arch Package How many times Failed Fail message <br>
<br>
Click on Package -> Dependency Graph <br>
<br>
If GENTOO had everything emerging from any state (goal unattainable but \
desirable) that <br> would be a great advantage for the users. That \
feel of a lean mean machine that saves time - it's <br> tasty - new \
fans warranted.<br> <br>
</span><table>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td width=809><br><br>
<span style=" font-family:'courier new'; font-size: 10pt;">On 9 August 2014 \
04:58, Igor <</span><a style=" font-family:'courier new'; font-size: \
10pt;" href="mailto:lanthruster@gmail.com">lanthruster@gmail.com</a><span \
style=" font-family:'courier new'; font-size: 10pt;">> wrote:<br> \
Maintainers have no feedback from their ebuilds, they all do their best but \
there are no tools <br> to formalize their work. No compass. They have \
no access to user <br> space where the packages are installed, unaware \
how users are using their ebuilds. It's the design <br> failure that \
hunts Gentoo from the start - no global intellectual bug tracking system. \
Doing not mistakes<br>
- not possible, the automated tracking sub-systems should be there but... \
we are where we are. <br> 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 failing : </span><a style=" \
font-family:'courier new'; font-size: 10pt;" \
href="http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126">http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126</a><br>
<br>
<span style=" font-family:'courier new'; font-size: 10pt;">But its a lot of \
work investment to support.<br> <br>
And beyond "it installs" and "its tests pass", its piratically infeasible \
to track software failing beyond there.<br> <br>
And some of the reasons we have dependency declarations are to avoid \
problems that will ONLY be seen at runtime and WONT be seen during \
installation or testing. ( Usually because the problem was found before \
there were tests for it )<br> <br>
For that, only manual feedback systems, such as our present bugzilla, are \
adequate. <br> <br>
<br>
-- <br>
Kent<span style=" font-size: 8pt;"><b> <br>
<br>
<span style=" color: #cccccc;">KENTNL</span></b><span style=" color: \
#cccccc;"> - </span></span></span><a style=" color: #cccccc; \
font-family:'courier new';" \
href="https://metacpan.org/author/KENTNL">https://metacpan.org/author/KENTNL</a><br>
</td>
</tr>
</table>
<br><br>
<br>
<br>
<span style=" font-family:'arial'; color: #c0c0c0;"><i>-- <br>
Best regards,<br>
Igor \
</i></span><a style=" \
font-family:'arial';" \
href="mailto:lanthruster@gmail.com">mailto:lanthruster@gmail.com</a></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic