Debian LTS Logo

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.

In January, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 23.75h for LTS (out of 30 max) and 20h for ELTS (max) of which I did 1.5h.

I couldn't work much on ELTS because there are very few sponsors left for oldoldoldstable (sic!), hence not many packages to support, hence not much possible work.

In a direct communication, one team member expressed that team workflow is to be discussed on a private mailing list because according to them these problems don't need to be discussed in public and only results count. I have an opposite approach -- anything that isn't strictly confidential / security-sensitive is to be discussed publicly. The Debian Social Contract says "We don't hide problems" so if we want to address problems in a Debian workflow, this is to be public. What do you think?

ELTS - Wheezy

  • request supported packages list update
  • sqlite3: re-triage: drop as it just reached end-of-life
  • nss: re-triage: suggest clarification since package just reached end-of-life, yet claimed; actually a static build dependency of openjdk
  • python-apt: re-triage: claimed, checked actual EOL status with triager, unclaimed
  • python2.7: re-triage: was marked end-of-life, checked !EOL status with triager, marked for update

LTS - Jessie

  • wordpress: jessie triage (7 CVEs), security upload
  • tomcat7: start working then cancel work since it was unclaimed since 9 days yet 2 LTS members were already working on it
  • gpac: jessie triage (17 CVEs), reported new crash, reported invalid fix, security upload

Documentation/Scripts