<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 17/11/2016 14:49, Antoine Monmayrant
a écrit :<br>
</div>
<blockquote cite="mid:3e52-582db580-7-1f6b2d40@103877005"
type="cite">
<pre wrap="">Le Mercredi, Novembre 16, 2016 14:02 CET, Rafael Guerra <a class="moz-txt-link-rfc2396E" href="mailto:jrafaelbguerra@hotmail.com"><jrafaelbguerra@hotmail.com></a> a écrit:
</pre>
<blockquote type="cite">
<pre wrap="">Given its usefulness, shouldn't it be part of the main Scilab distribution, not an add-on?
</pre>
</blockquote>
<pre wrap="">
I totally agree with you!
I was about to add this precise comment to my previous email but changed my mind at the last minute.
I don't see exactly what it would take to "merge" it with core scilab and whether Scilab devs and the uman dev would agree on this...
</pre>
</blockquote>
<br>
Rafael, Antoine,<br>
<br>
Thanks for your support.<br>
<br>
I could easily agree on including uman and disp_usage in Scilab as
embedded functions. <br>
I already proposed this to some Scilab team members in springs 2015.<br>
However, for the time being, this would rather prevent improving and
updating uman as i do up to now:<br>
<ul>
<li>reviewing and merging contributions in Scilab is clearly a
tight bottleneck. It could be relaxed/released either by
allowing contributors merging some contents in the present
Scilab infrastructure, or after forking Scilab to build a new
version developed and maintained by contributors. For the time
being, i have rather stopped contributing, because posting
improvements without enough manpower to review and merge them is
useless and lost time. The pending list is long enough, and i
put other forges (improving gsort, histplot, etc) in standby for
the same reason. So, adding uman commits would presently be
counter-productive. Thinking about building a fork is more
useful.<br>
<br>
</li>
<li>uman works with open resources, such as the open list of ATOMS
modules, of FileExchange file sets, and other external
references. On some extend, this demands updating these lists. I
do it roughly twice a year. The next uman release will ease this
piece of work by digging in the ATOMS registry downloaded by the
ATOMS client. But this improvement won't do all the job. <br>
By the way, i -- as an individual -- make some selections,
because some modules or resources are not well packaged, or in
duplicate due to a bad management of versions, etc. Setting a
"grey or black list" is possible, and requires at least a yearly
maintenance, needing fast reviews and merge. If included in
Scilab, i guess that such a selection would require a <i>collective</i>
agreement. Harder to get it than doing things "alone".<br>
</li>
</ul>
This is the current situation.<br>
Best regards<br>
Samuel <br>
<br>
</body>
</html>