[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bioinfo package - maintenance of ...

From: Alois Schloegl
Subject: Re: bioinfo package - maintenance of ...
Date: Tue, 19 Dec 2017 14:33:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]