Re: Implementation of importdata belonging to Octave Core or Octave-Forge?

[Juan Pablo Carbajal]

On Mon, Oct 22, 2012 at 3:00 PM, Jordi Gutiérrez Hermoso
<address@hidden> wrote:
> On 20 October 2012 14:26, Juan Pablo Carbajal <address@hidden>
> wrote:
>
>> If you ask me, I think that including importdata in core so directly
>> wasn't really good. As I see it one of the roles of Octave Forge is
>> to provide a time for testing and eventually merge it into core.
>
> Is that the intended use case for OF? My reasoning was that importdata
> is a core Matlab function, so it should be in core Octave. I didn't
> think quality went into it. We already have tons of crappy code in
> core, and we have tons of amazing code in OF.
>
> Is the problem that you would like to work yourself on improving
> importdata but you see it as some sort of obstacle that it's in core?
> If so, we should work instead to make it easier for you and others to
> contribute to core functions. Supposedly, working with a DVCS is
> supposed to be one step towards making this less of an obstacle.
>
> - Jordi G. H.


I see no problem about working directly on core and is there is no
complains about adding "crappy" functions to core then I am ok with
it. However following the idea that there are less devs for core... is
it wise to do so?
I was just giving my opinion, if active devs developers are ok with
the inclusion, I can't say anything. :D

Applying the same criterion, "matlab core --> octvae core" the
function serial, implemented in the current instrumnet-control should
be considered for core. is that wise? Or since it is hardware/driver
dependent and requires more testing etc... is better to keep it in OF?

When do we move things from OF into core (given they are not too field
specific, like geometry and others)?