Possible topics (please add new ones):


* Python 3.6 as supported Python 3.X version in Stretch?
	python3.5 (release team)
* git-dpm in DPMT:
  - are we happy with it?
  - should PAPT use it as well?
  - what about gbp? (in PAPT, to test it)

* removing dh-python from python3's Depends (still not there)
  https://lintian.debian.org/tags/missing-build-dependency-for-dh-addon.html
  (not all packages detected, patch to lintian submitted:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740161;msg=19)
  `grep-dctrl -n -s Package -FSection python -a --not -FBuild-Depends,Build-Depends-Indep dh-python /var/lib/apt/lists/*Sources` lists 748
  384 in unstable.

* removing old dh_python2 from python-defaults (still not there)
  - dh-python needs to be listed in Build-Depends of all packages that use it
  (https://bugs.debian.org/740161)

* pypy
* pypy3
  - sharing dist-packages with Python 3.x
  - do we need dh_pypy3?
  - pypy3 itself written in python2

* Python 3.x:
  - limiting list of supported versions per file / directory
    (right now it's possible only in private directories, not in dist-packages;
     does upstream still want to fix it on their side?)
  - dh_python3 maintainer scripts: should we switch to triggers? (related to ^^)
  - should we stop providing python-foo (i.e. Python 2.X) binary packages?
    ... in new packages at least (or by default in tools like pypi2dsp)?
  - dropping python2 itself still means changing all the package builds to
    no longer build python2 binaries.
  - remove python2 modules without reverse dependencies? already encouraged.
    identify modules without python3 and check portability.
  - discourage new python2-only modules.
  - Why are we the ones wanting to force people to change? its upstreams decision
  	-> Because Py2 support from upstream is EOL, and we have no choice, 
  	   unless someone volunteers to maintain the Py2 interpreter past the EOL.
  	   -> orphan py2 and see what happens, don't remove stuff thats not broken
  	   	-> No security support == broken
  	   	   -> what still uses py2 will not be relevant for security there
  	   	     is lots of stuff without security support in debian
  	   	     	-> Please file a bug for these, and we'll remove them from Debian :)
  	   	-> how about seeing how many security issues appear until 2020 and then decide
  	   		-> Waiting for 2020 isn't a smart idea, we'd better act ASAP.
    	   		  -> why?
    	   		 	-> Because the transition will take an awful amount of time
    	   		 	  -> it will never happen at all for some software
    	   		 	  -> Let's remove these software who aren't maintainable
    	   		 	  -> the software is not in debian in the first place
    	   		 	  -> Great, not our problem then!
    	   		 	  -> so debian does not provide infrastructure anymore?
    	   		 	  -> It only provides those who are maintainable for security. Situation can change if you volunteer for doing security backport for Py2.


* what else can we automate?
  - dh_python{2,3} improvements?
  - pybuild improvements?
  - autopkgtest patches?
  
* Use of debian python packages in virtualenvs (perhaps not debian specific?)
  - developers often puts everything in a clean virtualenv
  - some binary packages (e.g. numpy and scipy) are very slow / hard to pip 
    install from source, is there an easy way to include specific system 
    packages in a virtualenv?

  Notes from ScottK (Since I won't be there):
  If we release with two supported python3 versions, that means doubling the
  size of binary extensions since they'll need 3.5 and 3.6 versions.  I'd be
  inclined to stick with just 3.5.
  Personally, I'm happy with git-dpm.  Most of the problems I see with it is
  people not realizing we use it.  I'd prefer not to switch and to have PAPT
  move to it too (not that I have much in the way of time to help with
  migration).
  Do we have a use case for different pure python3 files per python3 version?  I
  think if that comes up, someome screwed something up (maybe there's a special
  case)?
  Can pybuild be the new default automatic python build system if it's present
  since we're moving to a new compat in debhelper?  It'd be nice to have that
  automatic so --with python2,python3 would be all you'd typically need in
  debian/rules.