This page keeps track of various tasks that need to be handled.

Try to minimise regressions using DEP-8 tests

autopkgtest (DEP-8) and can help to prevent (certain) regressions. We could include/add tests on important packages with regular updates. At least, before uploading packages with tests, autopkgtest should be run using a jessie image (since running on a local unstable is not fully reliable).

TODO items


Improve scripts to detect missing package assignments

There are many cases where a CVE should be assigned to multiple source packages (either because there are multiple copies of the same software, ex "tiff" and "tiff3", or because other source package are embedding the vulnerable software). It would be nice if our CVE triaging script could detect when we are missing some package assignments ...

See discussion starting at:

automatically strip no-dsa tags by gen-DLA

Sometimes issues tagged no-dsa are fixed by an upload. In such cases the no-dsa tag currently has to removed manually from CVE/list. It would be more reliable and convinient to do this with bin/gen-DLA , which then would strip existing no-dsa tags for CVE IDs passed to the script.

Implement script to dispatch frontdesk duties and document on tagging of unavailable weeks

The last manual and auto-assignment was not optimal. Someone (anyone) in the team or a script must distribute the FD duties. Previously to each dispatching, contributors need to tag their future unavailable weeks.

Improve documentation on frontdesk work: Handling bugs tagged no-dsa in oldstable

The reasons for a no-dsa in stable could no apply 100% in oldstable (next-point-release, lack of manpower). We need to improve the frontdesk documentation to explain how we deal with no-dsa tags. We should not follow blindly the debian security no-dsa tags.

DLAs on

DLAs are now visible on but there is still some manual work to be done and improved:


Improve the security-tracker to not break salsa

fix so that the security-tracker doesn't break salsa.d.o (a.k.a. data/CVE/list is too big, though the security team doesnt want to split the file...)

Find upstream developers who are willing to work on LTS support

For difficult packages (frequent security updates where backports are hard and require domain specific knowledge), we should try to identify upstream developers who are willing to do the backporting work. They could be paid by Freexian for the hours where we need them.

Possible packages where we might need such help:

Write a list of the persons identified somewhere and send the hourly rates of those persons to


Improve tools to automatically unclaim a claimed package after 2 weeks

As per the discussion started in Message-ID: <>