Re: bioinfo package - maintenance of ...

[Oliver Heimlich]

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

signature.asc
Description: PGP signature