I was saying the same thing in my head, but as i thought about it, if the cpython maint team (hi doko) wants it, I don't see why not :)
I phrased it in such a way in my mail that I feel comfortable sending my draft and then working out details without setting ftpteam policy first On Apr 15, 2015 6:50 PM, "Scott Kitterman" <deb...@kitterman.com> wrote: > On Wednesday, April 15, 2015 11:07:13 PM Matthias Klose wrote: > > On 04/15/2015 10:27 PM, Paul Tagliamonte wrote: > > > Heyya d-p, > > > > > > I'd like to send an email to d-d-a asking that project to consider no > > > longer creating new Debian tools in Python 2. > > > > > > I'd like this to have the endorsement of the team, so, does anyone > object > > > to me asking people to not write new tools in Python 2 only (prefer > > > alternative deps or porting), and only use Python 2 in very special > > > curcumstances or for legacy codebases (perhaps a pitch to move to > Python > > > 3), along with a note that we plan to deprecate Python 2 when upstream > > > support is gone (2020), which puts us on track for two cycles (Buster) > > > > > > > > > I'll make note of a team which should exist to help with such porting, > > > (I'm up to help with this) that was one of the items that came out of > > > the PyCon chit-chat. I got the sense from the room that this would be > > > OK, but just checking if anyone here has a substantive objection. > > > > > > If not, I'll send that out later on today/tomorow. > > > > sure, please could you also propose not to accept new packages which are > > Python3 compatible upstream, but use Python2 in the packaging? Same > thing > > for modules when Python3 is supported upstream, but only the Python2 > module > > is packaged. > > Do you expect the FTP Team to enforce this? If not them, who? While I > agree > with the idea, I don't think it's something that can be enforced more > broadly > than DPMT/PAPT. We can (and I thnk it's reasonable to say) that DPMT/PAPT > won't accept such packages, but I don't think we can keep them out of the > archive. > > Scott K
