[Scilab-users] ?==?utf-8?q? uman 2.1 is released

[Samuel Gougeon]

Le 17/11/2016 14:49, Antoine Monmayrant a écrit :
> Le Mercredi, Novembre 16, 2016 14:02 CET, Rafael Guerra <jrafaelbguerra at hotmail.com> a écrit:
>   
>> Given its usefulness, shouldn't it be part of the main Scilab distribution, not an add-on?
> 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...

Rafael, Antoine,

Thanks for your support.

I could easily agree on including uman and disp_usage in Scilab as 
embedded functions.
I already proposed this to some Scilab team members in springs 2015.
However, for the time being, this would rather prevent improving and 
updating uman as i do up to now:

  * 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.

  * 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.
    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 /collective/ agreement. Harder to get it
    than doing things "alone".

This is the current situation.
Best regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20161124/9cc06516/attachment.htm>