Maintainers of scientific applications: Please maintain tasks files! (Was: Bug#592701: science-statistics: typo in package description)
andreas at an3as.eu
Thu Aug 12 20:26:43 UTC 2010
sorry for quoting myself, but may be the previously choosen subject
might have hidden the problem a bit and after some investigation into
Debian Science tasks files I came to the conclusion that they are not
properly maintained. :-(
Just from watching the PTS mails what packages were updated and what
were moved to testing I found a bunch of packages which are not
registered in the tasks files. If we gain for some completion in
presenting scientific software we simply fail to do so.
On Thu, Aug 12, 2010 at 09:12:01PM +0200, Andreas Tille wrote:
> > Do you know if the wiki will be updated to present ghkl in the right
> > tasks ?
> The wiki is manually edited and I really hope it will NOT be updated.
> Why should it? We should really stop manually editing those Wiki pages
> because in contrary what people keep on telling you about Wikis: It just
> is outdated. The tasks pages of the Blends web sentinel will be
> updated once a day and they contain all needed information about the
> packages and are contain really the latest information.
This statement is only true if we work together in registering packages
in the tasks pages. To make it more clear what this means I would like
to explain in short the phases of getting a package into Debian and how
this is reflected in the blends stuff.
The best way to do would be to register the prospective package
just now. There are examples in the tasks files and it is also
explained in the docs.
An example which shows the effect of registering a prospective
package can be sen for instance in the case of avl
Please note: The Long description has to be specified in the
field "Pkg-Description" (NOT Description - see the bug in the
subject of this mail).
My personal policy is: I'm registering WNPPs for any package which
is relevant for Debian Med, but my time does not allow to do the
same for Debian Science. I sometimes just add the package and
WNPP bug number to make sure the package will be there once it
is uploaded (but it does not show up on the tasks pages by only
specifying WNPP bug number)
2. Upload to new
Once a package is in the new queue there is no extra information
needed any more, because the new queue is parsed for packages
mentioned in the tasks file. This can be seen after the next
cron run in the example of libmadlib-dev
3. Accepted by ftpmaster and upload to unstable
At least at this point the package should be registered in the
according tasks file and IMHO the easiest way would be if the
maintainer would care for this. He just knows which task fits
best and he watches the package most closely.
4. Package moves to testing
Once a package is in testing it is registered as Recommended
package (instead of only Suggested) after releasing the next
version of Debian Science metapackages
5. Stable release
Everybody who installs a science metapackage will learn about
the registered packages (and might fail to realise those who are
We are currently close to a stable release and probably have only one
chance to fix the tasks files to be released in Squeeze. So maintainers
of scientific packages please do your homework NOW. If you have no idea
how to edit the tasks files (any DD has commit permissions to SVN) feel
free to send me a patch or just write an e-mail to the list what you
think should be changed in the tasks files.
This is also a simple task for general readers of this mailing list who
are not actually packaging software: Just browse the tasks pages and
watch out what packages might be missing.
Note: I CAN NOT do this on my own and probably nobody can because I'm
just lacking the knowledge to properly categorise those packages nor
do I know all the packages inside Debian.
So please provide some input - it is needed right now.
>  http://blends.alioth.debian.org/science/tasks/
(not available at the time of writing)
More information about the debian-science-maintainers