[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