TODO

things to do for piuparts
=========================

Please also check the BTS, especially the bugs with a severity higher than
wishlist!


for 0.5x:

- make piuparts-master + piuparts-slave packages work out-of-the-box:
  * piuparts-slave.postrm purge: clean up /var/cache/piuparts/tmp/
  - conf/piuparts.sudoers should be split for master+slave packages.
  - ship sane minimal sudoers in p-s.deb than can be enabled by default do we
    really need anything else than running piuparts and piuparts_slave_*
    as root?
  - verify that all scripts in $user/bin/ also work from master-slave packages
    eventually enable some conjobs in the packages
  - slave.postinst should setup ~piupartss/.ssh/known_hosts from /etc/ssh, even
    if only for localhost
  - slave.postinst should setup ~piupartsm/.ssh/authorized_keys using triggers
    dpkg-trigger piuparts-master-please-install-the-slave-key
  - split /etc/piuparts/piuparts.conf in /etc/piuparts/master.conf and
    /etc/piuparts/slave.conf?! or use /etc/default/slave to define sections?
    debconfify piuparts.conf? allow preseeding of mirror, master, ...

- merge/cleanup README_piatti.txt and README_server.txt?

- use cdn.debian.net as mirror default (instead of "your.mirror.here") and
  provide a debconf template to overwrite this.  or http.debian.net ?

- in maintainer view: sort buggy states up again

- more stats and graphs:
  - packages processed per day (in total and per slave)
    * master writes submissions.txt per section since 0.45
  - # of open bugs with tag piuparts
  - generate http://piuparts.debian.org/stable/states.png + testing.png from
    existing data

- sometimes a chroot doesn't get removed on piatti - find out why and fix it.
- slave_run: cleanup stale proc mountpoints -> there is
  ~piupartss/bin/slave_cleanup which should be executed at the beginning of
  slave_run

- handle .udebs more gracefully, see #699160 for details.

- re-read all documentation carefully and update were needed.


for 0.6x:


- generate piuparts.1.txt automatically from piuparts.py - see this blog post
  for a nice howto:
  http://andialbrecht.wordpress.com/2009/03/17/creating-a-man-page-with-distutils-and-optparse/
  - though this seems pretty complicated... maybe rather grep for
    parser.add_option and help= in piuparts.py ?!

- rework known_problems:
  - use a number prefix for sorting
  - add title information
  - piuparts-report: "discover" the available known_problems, dont hardcode the
    list
  - drop _issue/_error duplication, have flags inside to indicate thether to
    generate _issues.tpl (pass/) and/or _error.tpl (fail/ bugged/ affected/)
  - replace COMMAND with INCLUDE and EXCLUDE regular expressions, replacing the
    existing shell calls, for an orders-of-magnitude speed improvement in kpr
    creation
  - rework known problems to a python-friendlier format

- accept a PIUPARTS_CONF environment variable everywhere to point to a different
  piuparts.conf

- write reportbug-like wrapper for mass bug filing (start simple, make it more
  sophisticated later).

- rewrite piuparts-analyze to run over all sections and cache BTS responses

- "decorate" (strike-through) bug links generated by piuparts-analyze to
  indicate resolved state (take package version into account!)

- find_default_debian_mirrors: if parts[2] contains a / (think stable/updates
  for security.d.o), you can't ignore this, it will break later...

- make it possible to call aptitude (or similar) instead of apt-get and allow to
  override the commandline arguments.

- piuparts-slave: timestamps to log messages

- the templates used by update-reports.py should be taken from
  /etc/piuparts/templates/ and not be included in the python source

- check the logfiles (especially pass/) for
  * "Exception in thread"
  * java stacktraces
  * "Can't locate .* in @INC"

- test main without contrib/non-free in sources.list


for 0.7x and later:

- mounting /proc and perhaps others (usbfs, sysfs, /dev/pts, etc.) in the chroot
  might be a good idea because some packages might need this.

- report:
  - write stats about the reasons for failures, as its done with shell scripts
    now (piuparts-analyze.py is an existing "fragment".)
  - RSS feeds of logs
  - do more fancy R graphs, eg. also per state
  - sort packages on maintainer pages alphabetically (states first though)
  - link (and target) to piuparts.d.o configuration is static to piatti. should
    refer to the actual hosts configuration, eg goldwassers

- a redirect of http://piuparts.d.o/foo to http://p.d.o/source/f/foo.html would
  be nice

- monitor: master.log grows to fast and there is no mechanism to stop it
  - use logrotate

- really support multiple architectures:
  - piuparts-report should have a list of available arch and list packages only
    available on untested archs in a new state
    "(depends-)not-available-on-tested-archs"
  - master should (per default) only schedule packages which are not available
    on the master arch to slaves of different archs ->
    "schedule-evenly-to-slaves = no"

- piuparts-master: keep track of to whom a reservation was given

- piuparts can't currently test upgrades of required packages.  (Because they
  cannot be removed, it assumes these are untestable, which is only true for
  removal tests...

- not sure if it's a sensible thing to to, but provide a way to turn off
  debugging output for piuparts.py - see
http://docs.python.org/library/logging.html

- commandline-switches for all programms

- move shell cronjobs functionality into master, slave & report


1.0 should really have automated testing of piuparts itself...
-----------------------------------------------------------------

- create archive of broken packages to provide test cases for piuparts testing.

- create emacspeak-broken-dpkg-preconfigure package for broken repo. (then later
  put more broken packages in there and use that for testing piuparts)