Removing packages from Octave Forge

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

Re: Removing packages from Octave Forge

c.-2

On 9 Jan 2014, at 16:29, Jordi Gutiérrez Hermoso <[hidden email]> wrote:

> xOn Thu, 2014-01-09 at 15:27 +0100, c. wrote:
>> BTW, I propose to change the name of Agora. "Ουτοπία" or
>> "Καλλίπολις" would better reflect its development process ...
>
> Sorry. I am testing a new web host that should solve some of the
> issues. It's not exactly vaporware. I'm sorry this has taken so long.

No reason need to apologize, I didn't mean to blame anyone
and I'm sorry if I did sound so.

I just think we should focus on finishing Kallipolis (ehmmm ... Agora)
rather than mess up with Octave Forge to prepare for the "imminent switch".

> - Jordi G. H.
c.
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Thomas Weber-3
In reply to this post by Alexander Barth-3
On Thu, Jan 09, 2014 at 05:02:37PM +0100, Alexander Barth wrote:
> Dear all,
>
> Are there confirmed reports that those packages do not work anymore in
> recent versions of octave?

This approach doesn't work. We had Octave in Debian seg-faulting at
startup on some architecturves for *years*. As nobody was using the
software at all on these architectures, no bug about this was *ever*
reported.

Move the package into an archive and if someone complains, move it back.
The other way does not work at all.

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Thomas Weber-3
In reply to this post by PhilipNienhuis
On Thu, Jan 09, 2014 at 09:19:03AM -0800, PhilipNienhuis wrote:
> c.-2 wrote
> > On 9 Jan 2014, at 15:46, c. &lt;
> That would be good - having a section with packages marked "actively
> maintained" and another section (more to the bottom) marked "currently
> unmaintained".

Such a distinction exists for a long time - packages maintained by "The
Octave community" are effectively unmaintained. Don't overcomplicate
this - move the packages out of sight and if somebody complains, put the
relevant package back.

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Juan Pablo Carbajal-2
On Fri, Jan 10, 2014 at 8:18 AM, Thomas Weber <[hidden email]> wrote:
> packages maintained by "The
> Octave community" are effectively unmaintained

This might not apply anymore, since "The octave community" is also
used in packages that almost every OF dev has contributed. Example:
signal package.
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Alexander Barth-3
In reply to this post by Thomas Weber-3

Dear Thomas and Carnë ,
 
>
> Are there confirmed reports that those packages do not work anymore in
> recent versions of octave?

This approach doesn't work. We had Octave in Debian seg-faulting at
startup on some architecturves for *years*. As nobody was using the
software at all on these architectures, no bug about this was *ever*
reported.

That a package produces a segmentation fault on a rarely used architecture can also happen with a actively maintained software. If no one use the package on a specific architecture, how could the maintainers know that there is a problem?

Some packages are also simple script files. For example I use the mapping package for years and I never had a problem with it. There is no additional feature of this package that I would need. I am fine with the fact that there has no release since 2009.

To improve code quality, I would rather suggest to ask the maintainers (if they can be reached) to add a test script to their package which verifies the functioning of the package as a whole (e.g. test_<packagename>.m). This script could call for exemple the test code the individual file with the test function but it would also check if the functions work correctly together.  I can write such a test script for mapping. If a package fails its test suite, then we have, in my oppion, a more objective way to decide that this package should be removed from the "official" list of packages.

 Regards
Alex


Move the package into an archive and if someone complains, move it back.
The other way does not work at all.

        Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

marco atzeri-2
Il 1/10/2014 11:09 AM, Alexander Barth ha scritto:

>
> Dear Thomas andCarnë ,
>
>      >
>      > Are there confirmed reports that those packages do not work
>     anymore in
>      > recent versions of octave?
>
>     This approach doesn't work. We had Octave in Debian seg-faulting at
>     startup on some architecturves for *years*. As nobody was using the
>     software at all on these architectures, no bug about this was *ever*
>     reported.
>
>
> That a package produces a segmentation fault on a rarely used
> architecture can also happen with a actively maintained software. If no
> one use the package on a specific architecture, how could the
> maintainers know that there is a problem?
>
> Some packages are also simple script files. For example I use the
> mapping package for years and I never had a problem with it. There is no
> additional feature of this package that I would need. I am fine with the
> fact that there has no release since 2009.
>
> To improve code quality, I would rather suggest to ask the maintainers
> (if they can be reached) to add a test script to their package which
> verifies the functioning of the package as a whole (e.g.
> test_<packagename>.m). This script could call for exemple the test code
> the individual file with the test function but it would also check if
> the functions work correctly together.  I can write such a test script
> for mapping. If a package fails its test suite, then we have, in my
> oppion, a more objective way to decide that this package should be
> removed from the "official" list of packages.

this will also help disti package maintainer to report broken one
and to better select what to not package at all.

>   Regards
> Alex

on cygwin for 3.6.4 I was packing 70 ones, and I assume
at least a third colud be dropped for 3.8.0 effort

Regards
Marco






Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Julien Bect
In reply to this post by Alexander Barth-3
On 10/01/2014 11:09, Alexander Barth wrote:
> To improve code quality, I would rather suggest to ask the maintainers
> (if they can be reached) to add a test script to their package which
> verifies the functioning of the package as a whole (e.g.
> test_<packagename>.m). This script could call for exemple the test
> code the individual file with the test function but it would also
> check if the functions work correctly together.  I can write such a
> test script for mapping. If a package fails its test suite, then we
> have, in my oppion, a more objective way to decide that this package
> should be removed from the "official" list of packages.

I like this idea very much. I suggest to call the test function
PKG_TEST, in the spirit of PKG_ADD and PKG_DEL, and to make it possible
for package users to run the test suite using, for instance, "pkg test
PackageName". Just my two cents.

@++
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Philip Nienhuis
Julien Bect wrote
On 10/01/2014 11:09, Alexander Barth wrote:
> To improve code quality, I would rather suggest to ask the maintainers
> (if they can be reached) to add a test script to their package which
> verifies the functioning of the package as a whole (e.g.
> test_<packagename>.m). This script could call for exemple the test
> code the individual file with the test function but it would also
> check if the functions work correctly together.  I can write such a
> test script for mapping. If a package fails its test suite, then we
> have, in my oppion, a more objective way to decide that this package
> should be removed from the "official" list of packages.

I like this idea very much. I suggest to call the test function
PKG_TEST, in the spirit of PKG_ADD and PKG_DEL, and to make it possible
for package users to run the test suite using, for instance, "pkg test
PackageName". Just my two cents.
In principle I second this; but it just won't work on all packages for all functions.

E.g., in the io package I have some test scripts for all spreadsheet I/O functionality, that adapt to the situation on the box the io pkg gets installed on.
But the io package also contains various functions that have been there for a long time and that I don't really maintain. Some were contributed, all still seem to work and/or compile flawlessly. I've restyled some and for some even added some extremely simple tests; but as I'm not familiar with the purpose they serve I simply can't create really useful practical tests for them.

Then consider the general or miscellaneous packages, collections of functions with widely varying functionality. How to test text_wait bar or solvesudoku? I don't doubt it can somehow be done, but not without overstretching or unduly mis-prioritizing the limited developer time we have here.

Other hard-to-test issues concern what happens during package installation/uninstallation - I got bitten myself lately by such issues.

In a more positive sense, the way to go -as always- is to just start with some test scripts for some packages that don't have tests yet, rather than rolling out a scheme for all packages. We'll see what problems we get on the way.
I'd advise Alexander to proceed making a test script for the mapping package (that I also use, sporadically) even if he isn't package maintainer.

I had to invest quite a bit of time in making & debugging the test scripts for spreadsheet support, but looking backward I can only say that it really paid off in making maintenance easier (plus, I learned a lot from it, and it was fun).
So apart from discriminating between working and broken packages, formal test scripts also can help keeping package maintenance down.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Thomas Weber-3
In reply to this post by Alexander Barth-3
On Fri, Jan 10, 2014 at 11:09:33AM +0100, Alexander Barth wrote:
> Dear Thomas and Carnë ,
> That a package produces a segmentation fault on a rarely used architecture
> can also happen with a actively maintained software. If no one use the
> package on a specific architecture, how could the maintainers know that
> there is a problem?

Excatly. The questions now is: if no one uses an octave-forge package,
who should report problems about it?

> To improve code quality, I would rather suggest to ask the maintainers (if
> they can be reached) to add a test script to their package which verifies
> the functioning of the package as a whole (e.g. test_<packagename>.m).

At least for Debian, that is not needed. We run all (non-interactive)
tests in .m and .cc files when building a package. Now, in theory, a
failing test should prevent the package from being uploaded. In
practice, some packages have long-standing failures in their testsuite.

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Mike Miller
On Fri, 10 Jan 2014 07:22:58 -0500, Thomas Weber wrote:
> On Fri, Jan 10, 2014 at 11:09:33AM +0100, Alexander Barth wrote:
>> To improve code quality, I would rather suggest to ask the maintainers (if
>> they can be reached) to add a test script to their package which verifies
>> the functioning of the package as a whole (e.g. test_<packagename>.m).
>
> At least for Debian, that is not needed. We run all (non-interactive)
> tests in .m and .cc files when building a package. Now, in theory, a
> failing test should prevent the package from being uploaded. In
> practice, some packages have long-standing failures in their testsuite.

Even outside of Debian, we don't need new syntax or new conventions for
running package tests. Please, please, do not start committing test
scripts to package repositories. Just write %!test blocks for your
functions and use Octave's runtests command. If anything, maybe file a
wishlist bug for a "pkg test" command that is just a thin wrapper around
runtests.

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Alexander Barth-3



On Fri, Jan 10, 2014 at 1:45 PM, Mike Miller <[hidden email]> wrote:
On Fri, 10 Jan 2014 07:22:58 -0500, Thomas Weber wrote:
> On Fri, Jan 10, 2014 at 11:09:33AM +0100, Alexander Barth wrote:
>> To improve code quality, I would rather suggest to ask the maintainers (if
>> they can be reached) to add a test script to their package which verifies
>> the functioning of the package as a whole (e.g. test_<packagename>.m).
>
> At least for Debian, that is not needed. We run all (non-interactive)
> tests in .m and .cc files when building a package. Now, in theory, a
> failing test should prevent the package from being uploaded. In
> practice, some packages have long-standing failures in their testsuite.

Even outside of Debian, we don't need new syntax or new conventions for
running package tests. Please, please, do not start committing test
scripts to package repositories. Just write %!test blocks for your
functions and use Octave's runtests command. If anything, maybe file a
wishlist bug for a "pkg test" command that is just a thin wrapper around
runtests.

Thank you for pointing runtests out. I was not aware of this script and it would be indeed sufficient in my opinion to test the well functioning of a package. The "pkg test" command would be a convenient way for the user to test the package.

However, if the package should also work on matlab, one should also be able to use the test suite on matlab. I don't know if this possible with %!test blocks. Even if the package should only work on octave, but implements a functionality in matlab, it is very useful to be able to run the test suite in matlab in order to make sure that the test suite is correct.

I would like to come back to the original question about removing package from octave forge (rather than disgressing about whether one should use test blocks or not). I think that it is preferable to base such decision if the test code fails or not (rather than release date). If a package does not contain a test suite and if the maintainer (or anybody else) has no time to write one, it can dropped from the "official list". But if the package still works well, I would suggest to keep it visible.

regards,
Alex


 

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Nir Krakauer-2
In reply to this post by Carnë Draug
gsl is useful and in my opinion should be retained. I'd be willing to take over as maintainer if the listed one is not available.
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Philip Nienhuis
In reply to this post by Mike Miller
Mike Miller wrote
On Fri, 10 Jan 2014 07:22:58 -0500, Thomas Weber wrote:
> On Fri, Jan 10, 2014 at 11:09:33AM +0100, Alexander Barth wrote:
>> To improve code quality, I would rather suggest to ask the maintainers (if
>> they can be reached) to add a test script to their package which verifies
>> the functioning of the package as a whole (e.g. test_<packagename>.m).
>
> At least for Debian, that is not needed. We run all (non-interactive)
> tests in .m and .cc files when building a package. Now, in theory, a
> failing test should prevent the package from being uploaded. In
> practice, some packages have long-standing failures in their testsuite.

Even outside of Debian, we don't need new syntax or new conventions for
running package tests. Please, please, do not start committing test
scripts to package repositories. Just write %!test blocks for your
functions and use Octave's runtests command.
A noble aim, but it's simply not going to work for all cases.

In io the spreadsheet test scripts *may* be converted to tests (yes I've looked at that some years ago), but that comes a.o., at the cost of undue code bloat for each individual test. With consequentially inflated test maintenance burden.
Parts could be moved to test sections; but taking the present test suite apart would undoubtedly increase complexity for me beyond reason.
In any case I'm not going to do that in the foreseeable future. The way I've set it up since a few years proved to be the most efficient and effective for me (as package maintainer).

I'm not blind for the needs of distro packagers; but:
(1) Even if formal tests would run fine in their test environments, there's still no 100 % guarantee that out there, in practice, the io package would run fine as well. There are simply too many circumstances and requirements beyond immediate control of packagers.
(2) Not everyone is installing Octave and OF packages through a distro package manager.

Having some test stuff around that interactively helps diagnosing the local situation makes self-help and support significantly easier than %!tests that only yield binary "pass/fail" info.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Carnë Draug
I have created a new section for unmaintained packages. They are
listed at the bottom of the packages list, explaining they may still
be working and with changes on the repositories. There are links for
the repositories and the released files, I encourage to still fill bug
reports, and suggest to join as a maintainer if they care about one.

While "maintained by the Octave community" is usually a nice way to
say "unmaintained", that's not always the case. Some are actually
being maintained such as signal or optim. They appear on the top list
of packages.

I know that release date is not a perfect indication of brokeness but
in the absence of tests and user reports, it's what we have. I'm sure
there's more recently released packages that are broken. If you know
of any, let me know and I'll change its status.

Everything is still accessible and can be downloaded easily.

I have also added a new section for packages that no longer exist
(merged together or renamed).

I had to mess with the php that deals with those pages, so if you find
any issues, let me know.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Philip Nienhuis
Carnë Draug-4 wrote
I have created a new section for unmaintained packages. They are
listed at the bottom of the packages list, explaining they may still
be working and with changes on the repositories. There are links for
the repositories and the released files, I encourage to still fill bug
reports, and suggest to join as a maintainer if they care about one.
The link to the File Release System leads to a non-obvious location.

A better URL would be:

http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/

While "maintained by the Octave community" is usually a nice way to
say "unmaintained", that's not always the case. Some are actually
being maintained such as signal or optim. They appear on the top list
of packages.

I know that release date is not a perfect indication of brokeness but
in the absence of tests and user reports, it's what we have. I'm sure
there's more recently released packages that are broken. If you know
of any, let me know and I'll change its status.

Everything is still accessible and can be downloaded easily.

I have also added a new section for packages that no longer exist
(merged together or renamed).

I had to mess with the php that deals with those pages, so if you find
any issues, let me know.
Looks good!

Thanks Carnë

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Carnë Draug
On 10 January 2014 20:01, Philip Nienhuis <[hidden email]> wrote:

> Carnë Draug-4 wrote
>> I have created a new section for unmaintained packages. They are
>> listed at the bottom of the packages list, explaining they may still
>> be working and with changes on the repositories. There are links for
>> the repositories and the released files, I encourage to still fill bug
>> reports, and suggest to join as a maintainer if they care about one.
>
> The link to the File Release System leads to a non-obvious location.
>
> A better URL would be:
>
> http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/

That link was there before, pointing to where the old monolithic
releases could be obtained. I just rewrote it and left the link. If I
change it, where would one know where to find them? ;)

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

c.-2
In reply to this post by Carnë Draug

On 10 Jan 2014, at 18:59, Carnë Draug <[hidden email]> wrote:

> I have created a new section for unmaintained packages. They are
> listed at the bottom of the packages list, explaining they may still
> be working and with changes on the repositories. There are links for
> the repositories and the released files, I encourage to still fill bug
> reports, and suggest to join as a maintainer if they care about one.
>
> While "maintained by the Octave community" is usually a nice way to
> say "unmaintained", that's not always the case. Some are actually
> being maintained such as signal or optim. They appear on the top list
> of packages.
>
> I know that release date is not a perfect indication of brokeness but
> in the absence of tests and user reports, it's what we have. I'm sure
> there's more recently released packages that are broken. If you know
> of any, let me know and I'll change its status.
>
> Everything is still accessible and can be downloaded easily.
>
> I have also added a new section for packages that no longer exist
> (merged together or renamed).
>
> I had to mess with the php that deals with those pages, so if you find
> any issues, let me know.
>
> Carnë

Carnë,

Could you please also move back the "integration" package?
I have packages that depend on it and are being actively used and developed.
If you need a maintainer to do so you can list me as the new maintainer.


c.
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Philip Nienhuis
In reply to this post by Carnë Draug
Carnë Draug-4 wrote
On 10 January 2014 20:01, Philip Nienhuis <[hidden email]> wrote:
> Carnë Draug-4 wrote
>> I have created a new section for unmaintained packages. They are
>> listed at the bottom of the packages list, explaining they may still
>> be working and with changes on the repositories. There are links for
>> the repositories and the released files, I encourage to still fill bug
>> reports, and suggest to join as a maintainer if they care about one.
>
> The link to the File Release System leads to a non-obvious location.
>
> A better URL would be:
>
> http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/

That link was there before, pointing to where the old monolithic
releases could be obtained. I just rewrote it and left the link. If I
change it, where would one know where to find them? ;)
Monolithic releases - that's not for archiving but rather for archeology.
And "where to find them" - isn't archeology all about digging around?

OK seriously now:
My point is that from that link you put up, on expects to see the individual archived packages; it isn't obvious to go to Parent folder and from there go to Individual package Releases.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Carnë Draug
On 10 January 2014 21:55, Philip Nienhuis <[hidden email]> wrote:

> Carnë Draug-4 wrote
>> On 10 January 2014 20:01, Philip Nienhuis &lt;
>
>> prnienhuis@.sf
>
>> &gt; wrote:
>>> Carnë Draug-4 wrote
>>>> I have created a new section for unmaintained packages. They are
>>>> listed at the bottom of the packages list, explaining they may still
>>>> be working and with changes on the repositories. There are links for
>>>> the repositories and the released files, I encourage to still fill bug
>>>> reports, and suggest to join as a maintainer if they care about one.
>>>
>>> The link to the File Release System leads to a non-obvious location.
>>>
>>> A better URL would be:
>>>
>>> http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/
>>
>> That link was there before, pointing to where the old monolithic
>> releases could be obtained. I just rewrote it and left the link. If I
>> change it, where would one know where to find them? ;)
>
> Monolithic releases - that's not for archiving but rather for archeology.
> And "where to find them" - isn't archeology all about digging around?
>
> OK seriously now:
> My point is that from that link you put up, on expects to see the individual
> archived packages; it isn't obvious to go to Parent folder and from there go
> to Individual package Releases.

You're right, don't worry. When I sent the previous email I had
already fixed it.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: Removing packages from Octave Forge

Carnë Draug
In reply to this post by c.-2
On 10 January 2014 21:02, c. <[hidden email]> wrote:

>
> On 10 Jan 2014, at 18:59, Carnë Draug <[hidden email]> wrote:
>
>> I have created a new section for unmaintained packages. They are
>> listed at the bottom of the packages list, explaining they may still
>> be working and with changes on the repositories. There are links for
>> the repositories and the released files, I encourage to still fill bug
>> reports, and suggest to join as a maintainer if they care about one.
>>
>> While "maintained by the Octave community" is usually a nice way to
>> say "unmaintained", that's not always the case. Some are actually
>> being maintained such as signal or optim. They appear on the top list
>> of packages.
>>
>> I know that release date is not a perfect indication of brokeness but
>> in the absence of tests and user reports, it's what we have. I'm sure
>> there's more recently released packages that are broken. If you know
>> of any, let me know and I'll change its status.
>>
>> Everything is still accessible and can be downloaded easily.
>>
>> I have also added a new section for packages that no longer exist
>> (merged together or renamed).
>>
>> I had to mess with the php that deals with those pages, so if you find
>> any issues, let me know.
>>
>> Carnë
>
> Carnë,
>
> Could you please also move back the "integration" package?
> I have packages that depend on it and are being actively used and developed.
> If you need a maintainer to do so you can list me as the new maintainer.

There's a licensing issue with that package. We are releasing it under
GPLv2+ but no file has the license specified. There's a file on the
docs folder with an email from the authors saying that we can
distribute it with Octave, but in no place do they mention a license.
Could you please confirm this?

I have just created a mercurial repository for the integration package.

Carnë
123