[Pre-RFA] Intending to drop twenty-some packages
Given my available time and all the things competing for it (work, family,
other hacking endeavours [quantian, a few small code projects, ...],
running, ...), I have too many packages to continue to do a reasonable or
better job at keeping the packages in shape.
So from the 80+ packages I have, a few may be better off in new and caring
homes. I intend to keep the R stuff (but may remove a few CRAN packages),
the small Perl stuff I authored or adopted upstream, Quantlib, Gretl, and a
handful of other things. This leaves the following packages or groups of
* the Octave complex
- octave2.0 (to be removed once sarge is release; frozen upstream ages ago;
one bug that'll never get fixed, we can barely build it as it
requires g++ pre-3.0)
- octave2.1 (two minor bugs against the emacs mode, one other bug)
- octave-forge (pretty active and by now pretty large with many
build-depends; very well maintained upstream by Paul Kienzle)
- semidef-oct (needs rebuilds with every octave2.1 build)
- octave-matcompat (predecessor to octave-forge, can be removed soon)
- octave-ci (large chunks of it now in octave-forge and octave2.1)
- octave-epstk (active upstream)
- matwrap (dead upstream)
- inline-octave (Perl package, see above)
I have tried to unload this onto Rafael for a few years now, but he can't
take Octave either. This may be best served by a maintainer group via
alioth, and I could be persuaded to help. But I can't set up such a group
or lead it, for lack of time.
Octave has an outstanding author in John Eaton with whom I have worked
very well over the years. The same can be said of Paul Kienzle for
* the gsl set:
The two doc packages are currently a week behind packaging the new upstream
gsl. Well maintained upstream, maybe two releases a year. This should
probably go to another egghead ph.d. type, preferably in sciences. Hi Chris.
This is all very well maintained upstream. Two nuisance bug reports on the
doc package, one ftbfs that is in explicable to me.
* the Perl "spreadsheet" complex:
- spreadsheet-parseexcel (2 old open bugs, forwarded ages ago)
- dbd-excel (1 old open bug, forwarded)
The only one that moves is spreadsheet-writeexcel. All fairly standard Perl
packages, but would make sense to keep them together.
* other Perl packages:
- inline-octave [ related to Octave ]
All bug-free and straightforward. Stale apart from dbd-odbc, they don't
seem to move much upstream anymore.
* bc (with binary packages bc and dc)
Pretty stale upstream, has 5 open bugs most of which are feature requests
that are unlikely to ever be addressed. Most of these have been forwarded.
Given its "Priority: standard", someone with a tad of experience should
- afio (2 open bugs, active upstream, pretty straightforward)
- time (dead upstream)
- tob (fairly dead upstream despite CPR and a new upstream author recently)
- wajig (very active upstream, and well maintained upstream)
Please CC me on follow-ups to debian-devel, or email me directly if you have
any interest. I should follow up with RFA and O bug reports over the next
few weeks, but doing this informally first may be simpler. Or maybe not.
Better to have an approximate answer to the right question than a precise
answer to the wrong question. -- John Tukey as quoted by John Chambers