[Pkg-octave-devel] New potential packager

[Thomas Weber]

On Wed, Feb 22, 2012 at 08:28:41AM +0100, Juan Pablo Carbajal wrote:
> I think OF philosophy is not clearly defined. As you said, and I think
> that is the point of having it, OF has packages from pro-developers
> and from amateurs as well. In particular OF gives the opportunity to
> collect code generated by specialist of other fields outside Computer
> Science and not all these people know how to do/maintain a package,
> nor I think they will be interested in learning how to do it.
> Nevertheless, they can code in Octave and they can contribute with
> good algorithms. I think requiring for OF developers higher packaging
> standards will eventually slow the project down.

Most new code should probably land in 'miscellaneous', especially if
it's just .m code with no external dependencies.
> 
> In relation to what I said and was not easily understood, for example,
> the package "miscellaneous"(http://octave.sourceforge.net/miscellaneous/overview.html)
> is just a collection of m-files, no dependency with other Debian
> packages or external libraries. Octave has a function to install
> packages directly from OF servers (the function is not the best, but
> it works and we must improve it!), and it can handle internal
> dependencies (dependencies within Octave). This package is an example
> of "stand-alone" package.

$ grep misc $(find -name DESCRIPTION)
This shows that four packages depend on miscellaneous. If you do not
package it, you cannot package those packages (statistics, vrml,
financial, optim) either.


> On the other hand, there is the package "symbolic"
> (http://octave.sourceforge.net/symbolic/overview.html) which is based
> on GiNaC and CLN. Clearly this package does depend on at least one
> external library and that one is packaged for Debian. In this case it
> is almost required that the symbolic package respects and complies
> with a packaging standard. This is an example of a not stand-alone
> package.
> I believe, that big/complex packages like this have more chances of
> being kept by a proper maintainer, and depending on their popularity,
> taken over by another one, in case it is orphaned. Therefore I do feel
> that only this kind of packages are good candidates to be Debian
> packaged, and are worth the effort of this group.

You have chosen the wrong example for your arguments :)
'symbolic' was umaintained for years and just now, Jordi tries to revive
it.

> Regarding the issue of orphaned packages. The packages miscellaneous,
> audio and signal, are examples of projects that were abandoned by
> their original maintainers and taken over by the OF community.

miscellaneous is special in that lots of people commit to it. audio has
seen two commits in 2011 and none in 2010. Personally, I don't think
that the two commits from 2011 count as maintenance, but maybe audio is
feature complete.

> @Thomas: Are this the examples you were missing?
I don't have any specific package in mind. Some time ago, I looked at
the commits in octave-forge. About 2/3 of all packages hadn't seen a
commit in 12 months at that point.

> If you look at them you will see that those packages are
> "stand-alone", and I can tell you that the people who took over their
> maintenance are not "gurus" nor even experienced packagers. As I said
> before, given the heterogeneity of OF, that Thomas cleverly noticed,
> there should be room for these people and their contributions (IMHO).

That's not a problem at all. However, there should be some convergence
in packages, quality and standards. Examples of things that are simply bad:
1) We have somebody working on a new control package. Instead of doing
this work in the existing control package, we now have 
	main/control
	extras/control-devel
	extras/control-legacy
Now, imagine you are a new octave-forge user - which package will you
use?

2) There's an unmaintained quaternion package, the original author died
some years ago. So, we now have
	main/quaternion
	extras/quaternion_oo

> So, my proposal is to start discussing with the current OF admins
> about a consistent labeling of the packages, so that this group can
> take care only of the ones that really need to be packaged. I think
> this could considerably reduce the list of lintian warnings and
> increase the speed of package release. What do you say?

I don't think that we have that many lintian warnings. And the biggest
problem with the OF release process was fixed years ago (every package
was released as new, even if there was no changes since the previous
release).

	Thomas