[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[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:
  - gsl 
  - gsl-ref-html
  - gsl-ref-psdoc
  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-writeexcel 
  - spreadsheet-parseexcel (2 old open bugs, forwarded ages ago)
  - ole-storage-lite
  - 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:
  - dbd-odbc
  - finance-streamer
  - inline-octave [ related to Octave ]
  - math-numbercruncher
  - statistics-descriptive
  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
  take it.

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

Regards, Dirk

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

Reply to: