bioinfo package - maintenance of ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bioinfo package - maintenance of ...

Alois Schloegl-8
Dear Octave maintainers,


for several years, the bioinfo package does not have maintainer, I've
been adding three functions, and would like to maintain that package.

However, it is important to me, that this code can be used under matlab
as well, which means coding style that would work only in Octave but not
in Matlab would be a problem, and I could not contribute. Essentially,
I'd need to find or start another repository for maintaining these
functions.

Therefore, I'm asking whether it would be ok with you, if I take the
role of a maintainer for the bioinfo package.


Best regards,
  Alois





Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Olaf Till-2
On Sun, Dec 17, 2017 at 09:44:17PM +0100, Alois Schloegl wrote:

> Dear Octave maintainers,
>
>
> for several years, the bioinfo package does not have maintainer, I've
> been adding three functions, and would like to maintain that package.
>
> However, it is important to me, that this code can be used under matlab
> as well, which means coding style that would work only in Octave but not
> in Matlab would be a problem, and I could not contribute. Essentially,
> I'd need to find or start another repository for maintaining these
> functions.
>
> Therefore, I'm asking whether it would be ok with you, if I take the
> role of a maintainer for the bioinfo package.
>
>
> Best regards,
>   Alois
FTR, after pointing out that the existing functions of this package
comply with Octave coding style, the following had been my
(unanswered) reply to this request at

https://sourceforge.net/p/octave/package-releases/322/ :

I understand the need for running code both in Octave and in
Matlab. But if the code is to be maintained in collaboration, it can't
be kept in a style which deviates from the standard style of the
collaborating group.

I understand, too, that this removes your motivation to maintain the
code within the bioinfo package. But still, if you are willing to
contribute your new code as it is, GPL3+ licensed, this would be
nice. You could do it at the patch tracker. Since the bioinfo package
is currently comparatively simply structured, others (even me) could
take the task of adapting your code to Octave style. And since making
a bioinfo release is currently also comparatively simple, I can
probably do it myself once I get a hint that it's suitable to make a
new one.

Could you accept this compromise? If yes, do you give me leave to
adapt your current new code and to make a release?

BTW, there are some style elements which can be adhered to without
abolishing Matlab compatibility, as our rules for spaces. It would
help if you adhered to these, at least.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Alois Schloegl-8
On 2017-12-18 09:04, Olaf Till wrote:

> On Sun, Dec 17, 2017 at 09:44:17PM +0100, Alois Schloegl wrote:
>> Dear Octave maintainers,
>>
>>
>> for several years, the bioinfo package does not have maintainer, I've
>> been adding three functions, and would like to maintain that package.
>>
>> However, it is important to me, that this code can be used under matlab
>> as well, which means coding style that would work only in Octave but not
>> in Matlab would be a problem, and I could not contribute. Essentially,
>> I'd need to find or start another repository for maintaining these
>> functions.
>>
>> Therefore, I'm asking whether it would be ok with you, if I take the
>> role of a maintainer for the bioinfo package.
>>
>>
>> Best regards,
>>   Alois
>
> FTR, after pointing out that the existing functions of this package
> comply with Octave coding style, the following had been my
> (unanswered) reply to this request at
>
> https://sourceforge.net/p/octave/package-releases/322/ :
>
> I understand the need for running code both in Octave and in
> Matlab. But if the code is to be maintained in collaboration, it can't
> be kept in a style which deviates from the standard style of the
> collaborating group.
>
> I understand, too, that this removes your motivation to maintain the
> code within the bioinfo package. But still, if you are willing to
> contribute your new code as it is, GPL3+ licensed, this would be
> nice. You could do it at the patch tracker. Since the bioinfo package
> is currently comparatively simply structured, others (even me) could
> take the task of adapting your code to Octave style. And since making
> a bioinfo release is currently also comparatively simple, I can
> probably do it myself once I get a hint that it's suitable to make a
> new one.
>
> Could you accept this compromise? If yes, do you give me leave to
> adapt your current new code and to make a release?


Dear Olaf,


If you insist on a coding style that is incompatible to Mat*ab, I'll
need to setup another repository. My prefered solution would be not
doing that, but maintaining the code within the current repo. Since the
code is licensed with the GPL, the code is Free anyway, so it will not
be a big issue either way. There is "just" the additional effort of
maintaining two code bases - something I'd prefer to avoid.

Still, I'm hoping that it's acceptable to use a compatible coding style
within OF. Since the bioinfo package has no maintainer for several
years, I thought I can contribute here.


>
> BTW, there are some style elements which can be adhered to without
> abolishing Matlab compatibility, as our rules for spaces. It would
> help if you adhered to these, at least.

Sure, that should be no problem at all.

Best,
  Alois


>
> Olaf
>


Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

jbect
Le 18/12/2017 à 10:41, Alois Schloegl a écrit :

> On 2017-12-18 09:04, Olaf Till wrote:
>> On Sun, Dec 17, 2017 at 09:44:17PM +0100, Alois Schloegl wrote:
>>> Dear Octave maintainers,
>>>
>>>
>>> for several years, the bioinfo package does not have maintainer, I've
>>> been adding three functions, and would like to maintain that package.
>>>
>>> However, it is important to me, that this code can be used under matlab
>>> as well, which means coding style that would work only in Octave but not
>>> in Matlab would be a problem, and I could not contribute. Essentially,
>>> I'd need to find or start another repository for maintaining these
>>> functions.
>>>
>>> Therefore, I'm asking whether it would be ok with you, if I take the
>>> role of a maintainer for the bioinfo package.
>>>
>>>
>>> Best regards,
>>>    Alois
>> FTR, after pointing out that the existing functions of this package
>> comply with Octave coding style, the following had been my
>> (unanswered) reply to this request at
>>
>> https://sourceforge.net/p/octave/package-releases/322/ :
>>
>> I understand the need for running code both in Octave and in
>> Matlab. But if the code is to be maintained in collaboration, it can't
>> be kept in a style which deviates from the standard style of the
>> collaborating group.
>>
>> I understand, too, that this removes your motivation to maintain the
>> code within the bioinfo package. But still, if you are willing to
>> contribute your new code as it is, GPL3+ licensed, this would be
>> nice. You could do it at the patch tracker. Since the bioinfo package
>> is currently comparatively simply structured, others (even me) could
>> take the task of adapting your code to Octave style. And since making
>> a bioinfo release is currently also comparatively simple, I can
>> probably do it myself once I get a hint that it's suitable to make a
>> new one.
>>
>> Could you accept this compromise? If yes, do you give me leave to
>> adapt your current new code and to make a release?
>
> Dear Olaf,
>
>
> If you insist on a coding style that is incompatible to Mat*ab, I'll
> need to setup another repository. My prefered solution would be not
> doing that, but maintaining the code within the current repo. Since the
> code is licensed with the GPL, the code is Free anyway, so it will not
> be a big issue either way. There is "just" the additional effort of
> maintaining two code bases - something I'd prefer to avoid.
>
> Still, I'm hoping that it's acceptable to use a compatible coding style
> within OF. Since the bioinfo package has no maintainer for several
> years, I thought I can contribute here.

My opinion : 1) more maintained OF packages is good ; 2) more
Matlab-compatible packages is good.

So I'm all in favour of Alois taking maintenance of this package and
making new contributions in a Matlab-compatible style,

@++
Julien



Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Michael Godfrey


On 12/18/2017 10:03 AM, Julien Bect wrote:
Le 18/12/2017 à 10:41, Alois Schloegl a écrit :
On 2017-12-18 09:04, Olaf Till wrote:
On Sun, Dec 17, 2017 at 09:44:17PM +0100, Alois Schloegl wrote:
Dear Octave maintainers,


for several years, the bioinfo package does not have maintainer, I've
been adding three functions, and would like to maintain that package.

However, it is important to me, that this code can be used under matlab
as well, which means coding style that would work only in Octave but not
in Matlab would be a problem, and I could not contribute. Essentially,
I'd need to find or start another repository for maintaining these
functions.

Therefore, I'm asking whether it would be ok with you, if I take the
role of a maintainer for the bioinfo package.


Best regards,
   Alois
FTR, after pointing out that the existing functions of this package
comply with Octave coding style, the following had been my
(unanswered) reply to this request at

https://sourceforge.net/p/octave/package-releases/322/ :

I understand the need for running code both in Octave and in
Matlab. But if the code is to be maintained in collaboration, it can't
be kept in a style which deviates from the standard style of the
collaborating group.

I understand, too, that this removes your motivation to maintain the
code within the bioinfo package. But still, if you are willing to
contribute your new code as it is, GPL3+ licensed, this would be
nice. You could do it at the patch tracker. Since the bioinfo package
is currently comparatively simply structured, others (even me) could
take the task of adapting your code to Octave style. And since making
a bioinfo release is currently also comparatively simple, I can
probably do it myself once I get a hint that it's suitable to make a
new one.

Could you accept this compromise? If yes, do you give me leave to
adapt your current new code and to make a release?

Dear Olaf,


If you insist on a coding style that is incompatible to Mat*ab, I'll
need to setup another repository. My prefered solution would be not
doing that, but maintaining the code within the current repo. Since the
code is licensed with the GPL, the code is Free anyway, so it will not
be a big issue either way. There is "just" the additional effort of
maintaining two code bases - something I'd prefer to avoid.

Still, I'm hoping that it's acceptable to use a compatible coding style
within OF. Since the bioinfo package has no maintainer for several
years, I thought I can contribute here.

My opinion : 1) more maintained OF packages is good ; 2) more Matlab-compatible packages is good.

So I'm all in favour of Alois taking maintenance of this package and making new contributions in a Matlab-compatible style,

@++
Julien


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
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Doug Stewart-4


On Mon, Dec 18, 2017 at 8:29 AM, Michael D Godfrey <[hidden email]> wrote:


On 12/18/2017 10:03 AM, Julien Bect wrote:
Le 18/12/2017 à 10:41, Alois Schloegl a écrit :
On 2017-12-18 09:04, Olaf Till wrote:
On Sun, Dec 17, 2017 at 09:44:17PM +0100, Alois Schloegl wrote:
Dear Octave maintainers,


for several years, the bioinfo package does not have maintainer, I've
been adding three functions, and would like to maintain that package.

However, it is important to me, that this code can be used under matlab
as well, which means coding style that would work only in Octave but not
in Matlab would be a problem, and I could not contribute. Essentially,
I'd need to find or start another repository for maintaining these
functions.

Therefore, I'm asking whether it would be ok with you, if I take the
role of a maintainer for the bioinfo package.


Best regards,
   Alois
FTR, after pointing out that the existing functions of this package
comply with Octave coding style, the following had been my
(unanswered) reply to this request at

https://sourceforge.net/p/octave/package-releases/322/ :

I understand the need for running code both in Octave and in
Matlab. But if the code is to be maintained in collaboration, it can't
be kept in a style which deviates from the standard style of the
collaborating group.

I understand, too, that this removes your motivation to maintain the
code within the bioinfo package. But still, if you are willing to
contribute your new code as it is, GPL3+ licensed, this would be
nice. You could do it at the patch tracker. Since the bioinfo package
is currently comparatively simply structured, others (even me) could
take the task of adapting your code to Octave style. And since making
a bioinfo release is currently also comparatively simple, I can
probably do it myself once I get a hint that it's suitable to make a
new one.

Could you accept this compromise? If yes, do you give me leave to
adapt your current new code and to make a release?

Dear Olaf,


If you insist on a coding style that is incompatible to Mat*ab, I'll
need to setup another repository. My prefered solution would be not
doing that, but maintaining the code within the current repo. Since the
code is licensed with the GPL, the code is Free anyway, so it will not
be a big issue either way. There is "just" the additional effort of
maintaining two code bases - something I'd prefer to avoid.

Still, I'm hoping that it's acceptable to use a compatible coding style
within OF. Since the bioinfo package has no maintainer for several
years, I thought I can contribute here.

My opinion : 1) more maintained OF packages is good ; 2) more Matlab-compatible packages is good.

So I'm all in favour of Alois taking maintenance of this package and making new contributions in a Matlab-compatible style,

@++
Julien


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.


--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Olaf Till-2
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 <
> [hidden email]> 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

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Alois Schloegl-7
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 <
>> [hidden email]> 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

















signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Doug Stewart-4
In reply to this post by Olaf Till-2


On Mon, Dec 18, 2017 at 12:29 PM, Olaf Till <[hidden email]> 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 <
> [hidden email]> 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

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

No I do not question you judgement on these things.
I just thought that if it is unmaintained now then it can't be that important to be in group 1
But if you think it should be in group 1 then I accept that.


--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

jbect
Le 18/12/2017 à 22:03, Doug Stewart a écrit :
On Mon, Dec 18, 2017 at 12:29 PM, Olaf Till <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Oliver Heimlich


Am 18. Dezember 2017 22:14:15 MEZ schrieb Julien Bect <[hidden email]>:

>Le 18/12/2017 à 22:03, Doug Stewart a écrit :
>> On Mon, Dec 18, 2017 at 12:29 PM, Olaf Till <[hidden email]
>> <mailto:[hidden email]>> 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 (515 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

jbect
Le 19/12/2017 à 06:10, Oliver Heimlich a écrit :
> (On a side note: interval is not Matlab compatible

My mistake.  I thought it was.  But symbolic is, isn't it ?


> 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.

Sure, I would also like to see more contributions happening ;-)

And you guys are really going to discourage someone who is willing to
contribute to an *unmaintained* package just because he wants to use %
instead of # and "end" instead of "endif", "endfor", etc. ?


Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Michael Godfrey


On 12/19/2017 07:41 AM, Julien Bect wrote:
Le 19/12/2017 à 06:10, Oliver Heimlich a écrit :
(On a side note: interval is not Matlab compatible

My mistake.  I thought it was.  But symbolic is, isn't it ?


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.

Sure, I would also like to see more contributions happening ;-)

And you guys are really going to discourage someone who is willing to contribute to an *unmaintained* package just because he wants to use % instead of # and "end" instead of "endif", "endfor", etc. ?

Right. We need all the help we can get. It is that simple.

Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Oliver Heimlich
In reply to this post by jbect


Am 19. Dezember 2017 08:41:38 MEZ schrieb Julien Bect <[hidden email]>:

>Le 19/12/2017 à 06:10, Oliver Heimlich a écrit :
>> 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.
>
>Sure, I would also like to see more contributions happening ;-)
>
>And you guys are really going to discourage someone who is willing to
>contribute to an *unmaintained* package just because he wants to use %
>instead of # and "end" instead of "endif", "endfor", etc. ?
No! That would be the worst possible outcome.

I can imagine three possible solutions.

1a) the unmaintained package becomes an external package where the coding style is not a requirement. This would still be an improvement over the current situation where the pkg is unavailable for the user.

1b) like above, but somebody (Olaf et al?) maintains a community clone package with Octave style. However, I'd say that we have better things to do...

2) the package is maintained in Octave style and a Matlab compatible version can be compiled by automatically replacing # with %, endif with end and so on (like doctest does it).

Best
Oliver

signature.asc (515 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Alois Schloegl-7
In reply to this post by Oliver Heimlich
On 2017-12-19 06:10, Oliver Heimlich wrote:

>
>
> Am 18. Dezember 2017 22:14:15 MEZ schrieb Julien Bect <[hidden email]>:
>> Le 18/12/2017 à 22:03, Doug Stewart a écrit :
>>> On Mon, Dec 18, 2017 at 12:29 PM, Olaf Till <[hidden email]
>>> <mailto:[hidden email]>> 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Alois Schloegl-8

It seems there are no further objections on me taking the role as
maintainer of the bioinfo package.

As discussed, this package will be maintained under a coding
style that is compatible to Octave AND Matlab. Both, Octave
and Matlab, are target platforms. If the code does not run
correctly on any of the target platforms, it is considered a bug.

  Alois





Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

jbect
Le 26/12/2017 à 22:05, Alois Schloegl a écrit :
> It seems there are no further objections on me taking the role as
> maintainer of the bioinfo package.
>
> As discussed, this package will be maintained under a coding
> style that is compatible to Octave AND Matlab. Both, Octave
> and Matlab, are target platforms. If the code does not run
> correctly on any of the target platforms, it is considered a bug.

Hi Alois,

Unfortunately, it seems to me that there *are* objections.  Indeed, the
current OF admins are Olaf Till and Oliver Heimlich, and :

1) Oliver seems to think that the package should be maintained in
"Octave style" (*) unless it is placed in the "external group".

2) Olaf seems to think that the package should be in the "community"
group (**).

Good luck with the negotiations ;-))

@++
Julien



(*) which, apparently, means using # instead of % among other things.

(**) however, to this day, no one in the community actually cared enough
about this package to actually maintain it...

Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Alois Schloegl-8
On 2017-12-26 23:53, Julien Bect wrote:

> Le 26/12/2017 à 22:05, Alois Schloegl a écrit :
>> It seems there are no further objections on me taking the role as
>> maintainer of the bioinfo package.
>>
>> As discussed, this package will be maintained under a coding
>> style that is compatible to Octave AND Matlab. Both, Octave
>> and Matlab, are target platforms. If the code does not run
>> correctly on any of the target platforms, it is considered a bug.
>
> Hi Alois,
>
> Unfortunately, it seems to me that there *are* objections.  Indeed, the
> current OF admins are Olaf Till and Oliver Heimlich, and :
>
> 1) Oliver seems to think that the package should be maintained in
> "Octave style" (*) unless it is placed in the "external group".
>
> 2) Olaf seems to think that the package should be in the "community"
> group (**).
>
> Good luck with the negotiations ;-))
>
> @++
> Julien
>
>
>
> (*) which, apparently, means using # instead of % among other things.
>
> (**) however, to this day, no one in the community actually cared enough
> about this package to actually maintain it...
>


I thought I've given enough reasons.
Oliver, Olaf, do you still have objections ?

  Alois



Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Olaf Till-2
On Wed, Dec 27, 2017 at 12:20:28AM +0100, Alois Schloegl wrote:

> On 2017-12-26 23:53, Julien Bect wrote:
> > Le 26/12/2017 à 22:05, Alois Schloegl a écrit :
> >> It seems there are no further objections on me taking the role as
> >> maintainer of the bioinfo package.
> >>
> >> As discussed, this package will be maintained under a coding
> >> style that is compatible to Octave AND Matlab. Both, Octave
> >> and Matlab, are target platforms. If the code does not run
> >> correctly on any of the target platforms, it is considered a bug.
> >
> > Hi Alois,
> >
> > Unfortunately, it seems to me that there *are* objections.  Indeed, the
> > current OF admins are Olaf Till and Oliver Heimlich, and :
> >
> > 1) Oliver seems to think that the package should be maintained in
> > "Octave style" (*) unless it is placed in the "external group".
> >
> > 2) Olaf seems to think that the package should be in the "community"
> > group (**).
> >
> > Good luck with the negotiations ;-))
> >
> > @++
> > Julien
> >
> >
> >
> > (*) which, apparently, means using # instead of % among other things.
> >
> > (**) however, to this day, no one in the community actually cared enough
> > about this package to actually maintain it...
> >
>
>
> I thought I've given enough reasons.
> Oliver, Olaf, do you still have objections ?
You've repeatedly given your reasons. We understand them. I already
told you that.

Oliver and me have given you reasons for our point of view. You have
ignored them in your later posts.

I value the reasons given by Oliver and me higher than the reasons
given by you.

Oliver and me have given some ideas on how to proceed. You've just
done the contrary now, although we already objected to it.

Given this style of (non)co-operation, I think it unlikely that you
will become the maintainer of a package in the "community" group. Even
more since you seem to be determined not to follow Octave coding
style.

AFAIK this has been the first time an Octave Forge developer used his
general write access to do something explicitely objected to by the
Octave Forge administrators. It will have to be reverted. I'll wait
some time still for a possible agreement.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bioinfo package - maintenance of ...

Alois Schloegl-8
On 2017-12-27 21:19, Olaf Till wrote:

> On Wed, Dec 27, 2017 at 12:20:28AM +0100, Alois Schloegl wrote:
>> On 2017-12-26 23:53, Julien Bect wrote:
>>> Le 26/12/2017 à 22:05, Alois Schloegl a écrit :
>>>> It seems there are no further objections on me taking the role as
>>>> maintainer of the bioinfo package.
>>>>
>>>> As discussed, this package will be maintained under a coding
>>>> style that is compatible to Octave AND Matlab. Both, Octave
>>>> and Matlab, are target platforms. If the code does not run
>>>> correctly on any of the target platforms, it is considered a bug.
>>>
>>> Hi Alois,
>>>
>>> Unfortunately, it seems to me that there *are* objections.  Indeed, the
>>> current OF admins are Olaf Till and Oliver Heimlich, and :
>>>
>>> 1) Oliver seems to think that the package should be maintained in
>>> "Octave style" (*) unless it is placed in the "external group".
>>>
>>> 2) Olaf seems to think that the package should be in the "community"
>>> group (**).
>>>
>>> Good luck with the negotiations ;-))
>>>
>>> @++
>>> Julien
>>>
>>>
>>>
>>> (*) which, apparently, means using # instead of % among other things.
>>>
>>> (**) however, to this day, no one in the community actually cared enough
>>> about this package to actually maintain it...
>>>
>>
>>
>> I thought I've given enough reasons.
>> Oliver, Olaf, do you still have objections ?
>
> You've repeatedly given your reasons. We understand them. I already
> told you that.
>
> Oliver and me have given you reasons for our point of view. You have
> ignored them in your later posts.
>


Olaf,

I did not ignore them, but it seems besides the point. You mentioned
already that you see the need for code duplication. I'd prefer a model
that avoids this.

Your offer of converting my code to octave-only coding style is  a
non-offer as it would make the code unusable for an important target
group. My code runs already in octave and is licensed with GPL, your
statements still do not explain why you insist on octave-only coding style.

> I value the reasons given by Oliver and me higher than the reasons
> given by you.

From Olivers options, only option 1a) (external package) seems to come
close what I can contribute. Still, it is not clear what an "external
package" constitues of, it seems it means code duplication.

What I understand is that Oliver and You seem to emphasize the
"octave-only" coding style that is incompatible with Matlab.

>
> Oliver and me have given some ideas on how to proceed.

You mean your suggestion about code duplication ? You know that you
suggest a fork ?

> You've just
> done the contrary now, although we already objected to it.
>
> Given this style of (non)co-operation, I think it unlikely that you
> will become the maintainer of a package in the "community" group.


I've followed the rules asking on this list for taking the role of a
maintainer on this list. Non-cooperation would certainly be something
else. Getting no answer for 7 days from you as an "admin" of OF is
something I consider a non-cooperation.

(Actually, I assumed your silence means that you understand and accept
my reasoning, now I've learned I was wrong.)


> Even more since you seem to be determined not to follow Octave coding
> style.

This sounds like there is no possibility for me to maintain bioinfo
package within OF.

I've not decided yet, but most likely I'll set up a fork on github.
fast-export [1] seems to do a good-enough job of converting a mercurial
repository to git.

   Alois


[1] https://github.com/frej/fast-export



P.S.: For eight years, You had the chance do something about the bioinfo
package, only now - when I declare interest - you insist on maintaining
it ? Why do you find some other unmaintained OF package to work on ?
There seem to be plenty available [2].

    actuarial
    ad
    ann
    audio
    benchmark
    bioinfo
    civil-engineering
    engine
    fenv
    fl-core
    gnuplot
    informationtheory
    integration
    irsa
    mechanics
    missing-functions
    multicore
    nlwing2
    nnet
    oct2mat
    octcdf
    octgpr
    odebvp
    outliers
    pdb
    plot
    simp
    specfun
    special-matrix
    symband
    tcl-octave
    xraylib
    zenity

[2] https://octave.sourceforge.io/packages.php#unmaintained

12