• Python 2 removal
  - list of leaf packages
    + lintian warning/error about providing leaf package?
      - lintian doesn't know if a package is a leaf.
    + release tracker page with a list of (leaf) packages? (https://bugs.debian.org/931659) - [ACTION: olasd]
    + start by identifing team packages
    + usertags: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-python%40lists.debian.org
  - moving documentation to python-foo-doc package (/usr/share/python-foo/)
    or python3-foo (still /usr/share/doc/python-foo/)
    + policy needs to be updated?
    + Mailing list discussion https://lists.debian.org/debian-python/2019/07/msg00044.html
  - removal of (old) dh_python2 from python package (requires dh-python in Build-Depends)
  - Critical packages that require Python 2:
    + mercurial? (there's a fork)
  - Removal of /usr/bin/python?
    + dh_python2 is ready for this (except its own shabang is #!/usr/bin/python)
    + Provide a compatibility package for people who need it?
  - Release goal. Send a draft to debian-python, then to dda. [ACTION: p1otr]
  - Removal of pypy 2 leaf packages: yes
• The non-dbg Python 3.8 interpreter can import dbg extensions now, what should we do with the python3.8-dbg packages?
  - 3.8 expected in September.
  - Possibly adding some more sanitizers to python3.8-dbg ?
• Provide different versions of packages in different enviroments for application runtime isolated from system libraries, would that be possible? would there be a way to provide sensible support for that?
Something similar to:
https://www.softwarecollections.org/en/
https://modules.readthedocs.io/en/latest/
- there isn't really a good way to use multiple versions of modules on a single system under Debian
- you can use private modules and append to sys.path to find the "right" one
- you can use virtualenvs or similar, perhaps with dh_virtualenv
- containers and/or Docker are another way around this - a container per app
- the Debian archive / Python just doesn't have a good means to have two versions of the same thing
* Do we want all python-* modules maintained in DPMT?
- It seems like a positive thing to encourage maintainers to join DPMT and team-maintain packages, but it doesn't work for everyone
- Currently in DPMT people seem to maintain their own packages, mostly
- Team maintainership makes doing sweeping changes easier, for example the Python 2 removal: such changes can just be team uploads rather than NMU or other more complicated machinations

Graph of Py2 dependencies (ie: reverse depends of python2.7):
http://py2graph.infomaniak.ch/py2.7.deps.svg
The file took 15 minutes to generate with Graphvis, it's barely displayable on a Web browser. I can keep this graph up-to-date on a debian.net domain if the team think it's useful. Otherwise, do it yourself:

<script>
debtree -R --rdeps-depth=1000 --max-rdeps=2000 python2.7 | tee py2.7.deps.dot
dot -Tsvg -o py2.7.deps.svg py2.7.deps.dot
cp py2.7.deps.svg /var/www/html
</script>

People present in the meeting (name yourself so we know colors):
- zigo