Re: bioinfo package - maintenance of ...

[Alois Schloegl]

On 2017-12-19 06:10, Oliver Heimlich wrote:
> 
> 
> Am 18. Dezember 2017 22:14:15 MEZ schrieb Julien Bect <address@hidden>:
>> Le 18/12/2017 à 22:03, Doug Stewart a écrit :
>>> On Mon, Dec 18, 2017 at 12:29 PM, Olaf Till <address@hidden 
>>> <mailto:address@hidden>> wrote:
>>>
>>>     On Mon, Dec 18, 2017 at 09:33:44AM -0500, Doug Stewart wrote:
>>>     >
>>>     > I still think we need a 3 tier setup
>>>     > 1) pkgs like control statistics etc that should have strict
>> rules
>>>     > 2) pkgs like this that allows the maintainer more freedom.
>>>     > 3) pkgs that we only link to and the maintainer has full
>> control
>>>     over.
>>>
>>>     Currently we have a 2 tier setup.
>>>
>>>     1) As your 1), but seemingly you have different criteria to
>> choose
>>>        packages to include.
>>>
>>>     2) roughly as your 2), maintainer has full control except that
>> certain
>>>        rules have to be met. These rules don't include the coding
>> style.
>>>
>>>     If the maintainer wants a non-Octave coding style, this is what
>> group
>>>     (tier) 2) is for.
>>>
>>
>> It seems to me that some packages in the "community" group (interval, 
>> symbolic, perhaps others ?) use a Matlab-compatible coding style.
> 
> (On a side note: interval is not Matlab compatible and Joel did a great job 
> during last GSoC to fix my failures to follow Octave style in many places of 
> the package. It should have Octave style right now.)
> 
> The reason why Octave coding style is requested for packages is twofold: (a) 
> it shall allow to easily move a function from a package into Octave core or 
> into another package, (b) it shall be easier to contribute to community 
> maintained packages for all of us, which is easier when all packages follow a 
> corporate style.
> 
> Reason (a) is probably irrelevant for several packages. If only small 
> functions are of interest, the effort would be small to convert them into 
> Octave style. 
> 
> Reason (b) is really important because I'd like to see more contributions to 
> packages happening and a common style helps with that in the long run. It 
> simplifies to accept contributions if you don't have to reformat the patches.
> 
> Being Matlab compatible is always a maintenance overhead: Either you have to 
> provide two releases with automatic conversion between the styles (IIRC, 
> doctest does this) or you have to stick to Matlab compatible syntax only and 
> demand any contributor to follow the style. Since I don't have access to 
> Matlab I couldn't even check my contribution for Matlab compatibility. The 
> latter hopefully shows why it'd be a bad idea to accept community maintained 
> packages without Octave style.
> 
> Just my 2 cents
> Oliver
> 


For me its not a maintenance overhead, Matlab users are a target group I
care about. By using a coding style that works only in Octave, you are
preventing others from using free packages and toolboxes. You are
limiting the number of potential users for these packages and toolboxes.

Your assumption that it must be "either Octave or Matlab compatible
syntax" is a false dichotomy. It is possible to write code that works
well in both worlds. If you have not the possibility to check whether
the code runs on Matlab, you should at least others allow to fix that.
This is impossible if you enforce the octave-only coding style.

  Alois

signature.asc
Description: OpenPGP digital signature