[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