Re: Displaying an animation / "movie"

[Thomas Weber]

Am Montag, den 15.09.2008, 13:12 +0200 schrieb Francesco Potorti`:
> >> >Have you tried the 'video' package from Octave-Forge? I've never used
> >> >it, but I'm under the impression that it works with fairly recent
> >> >versions of ffmpeg.
> 
> Allright, waiting for Debian to produce an octave-video package, 

I don't intend to add any more octave-forge packages to Debian until
octave-forge's release process is fixed (and yes, it currently is
broken).

By "fixed" I mean that:
1) Packages that had no changes are not released with a new version
number.
2) The total number of packages is reduced.

1) Updating a package in Debian takes a minimal amount of time
regardless of how little changed. With 50 octave-forge packages, I spend
more than a whole day updating these packages. It already costs me a
whole day and we don't even have all packages in Debian.
That's just insane, given that a lot of these packages haven't changed
for over a year (and that's a conservative estimate, see below).

And no, the bundle is not a solution to that; it's just covering the
problem, not solving it.

2) I don't know what people are thinking, but not every little .m file
is worth an own package. 

Examples: 
Physicalconstants
*One* .m file, last code change in Feb 2007. Releases since then: 6(!)

That's five releases wasting the time of the octave-forge's release
manager and every downstream maintainer.

control:
Two .m files, last code change in Dec 2007. Released version then:
1.0.5, current: 1.0.7.

civil:
Three .m files, last code change not in SVN! All of them dealing with
ODEs, making them a perfect candidate for odepkg.


And so on. Guys, merging packages is far better then introducing your
own new pet package (e.g., "general" and miscellaneous" are perfect
candidates for merging - what's their difference, actually?). In fact,
would you go looking in the civil package for solving ODEs?

Personally I think that quite some packages should simply be kicked, as
their "maintainers" don't care about them. It's neither Soren's nor
David's job to care for this ever growing pile of code.

        Thomas