octave-maintainers
[Top][All Lists]
Advanced

[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: Mon, 18 Dec 2017 21:35:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 2017-12-18 18:29, Olaf Till wrote:
> On Mon, Dec 18, 2017 at 09:33:44AM -0500, Doug Stewart wrote:
>> On Mon, Dec 18, 2017 at 8:29 AM, Michael D Godfrey <
>> address@hidden> wrote:
>>> ...
>>>
>>> I definitely agree with Julien. Having a maintainer is very good. And, the
>>> maintainers should have
>>> reasonable freedom to make the choices that work best.
>>>
>>> Michael
>>>
>>
>> I agree with Michael who agrees with Julien.
>>
>> 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. But I'm not sure this helps in this case, since
> 'bioinfo' seems to aim for providing code compatiple with Matlabs
> bioinformatics toolbox, and such code we should only host under
> community control, in group 1).
> 
> I see no alternative to the code duplication mentioned by Alois. With
> the current state of the bioinfo package it would probably be possible
> for me to convert the new code myself into Octave style and make a
> release.
> 
> Do you question that it is desirable at all to adher to Octave coding
> style (including texinfo documentation) for collaborative work?
> 
> Olaf
> 


Olaf,


Yes, I question a coding style that *forces* developers to write code
that is incompatible to Mat*ab. What good does it do ?

Octave is designed to be compatible to Matlab. Why should not the same
be true for its packages a.k.a. toolboxes ?


Alois
















Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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