Things to do for piuparts
=========================

must for 0.36

- report:
--- write_sources_summaries() should be split in prepare_ and assemble_. assemble_ should use find_log() to build all needed pages
--- find_log() is not used atm
--- $package in $section
--- include pts links
--- include links to logfiles in source summary pages
--- include links to http://qa.debian.org/developer.php?login=$maintainer_email
--- dont write counts.txt if it has already been written that day
-- slave
--- mention distro when sending logs
--- slave_run: cleanup stale proc mountpoints
--- cronjob: warn about 10 or more tmp filesystems...
- then R
- take care of old conf files on upgrades
- take care of old pyc files from python-central
- test pipuparts with piuparts before uploading

for 0.37 and on

- report: write stats about the reasons for failures

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

- write slave-watcher to monitor hanging processes, eg. looping dpkg-preconfigure

- Check for and kill extraneous processes afterwards. Perhaps by checking
  whether their working directory is in the chroot.
  Introduce a whitelist of processes to wait for and assume it's an error 
  if those haven't been killed after $time=10min. see #387428

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

- publish FAI classes to setup piuparts.$fqdn automatically

- upgrade-reports 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"

- update-reports should generate source centered overview pages for packages

- 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"

- master.log grows to fast and there is no mechanism to stop it

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

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

- support for extra-packages-url (for volatile, security, etc)

- RSS feeds of logs

- not sure if it's a sensible thing to to, but provide a way to turn of debugging
  output for piuparts.py

- piuparts can't currently test postfix, since installing postfix removes
  exim and removing postfix would require re-installing exim, and that
  doesn't happen; there's other packages like that, too

- split the failed state into several problem-type failed states

- mounting /proc and perhaps others (usbfs, sysfs, /dev/pts, etc.) in
  the chroot might be a good idea because some packages might need this.
  Interestingly enough this currently seems to prevent start-stop-daemon
  from starting any daemons ;)

Low priority stuff (a.k.a. "nobody's said they must have it now")
-----------------------------------------------------------------

* make it possible to call aptitude (or similar) instead of apt-get and 
  allow to override the commandline arguments of the used program (to be 
  able to test with and without recommended packages or authentication).

* Kill children after a timeout to make sure the test doesn't run forever.


* include a test to see which packages which modify their own conffiles 
  so the user is presented with a dpkg conffile changed dialogue during
  the upgrade.  It would also be very interesting to see how many packages
  leave behind orphaned conffiles after purging a newer version which does
  not contain the files anymore.

* deal with packages that need to replace higher priority packages
  (which then need to be put back when the package is removed)

* Bill Allombert: Does piupart test whether packages trigger useless
  conffiles handling ? (i.e. dpkg pretend you have modified a conffile
  when it has not) this is one kind of bugs I would really get rid of.
  h01ger: #466118 sounds like it does.

* piuparts-slave: keep track of reservations permanently
* piuparts-master: keep track of whom a reservation is made
* piuparts-slave: timestamps to log messages
* piuparts-slave: if chroot.tgz is older than N hours, regenerate it
* piuparts-slave: make the chroot more minimial
* piuparts: upgrade the chroot before taking a snapshot of its files