> On Mar 25, 2019, at 3:15 AM, Amber Brown <hawk...@atleastfornow.net> wrote:
>
> Hi everyone,
>
> Since the Python 2 EOL date is rapidly approaching, I thought it was time we
> consider dropping Python 2 support.
>
> I personally find that Python 2 compat adds a huge amount of overhead when
> working on and maintaining Twisted, and think that with the current
> maintainer availability, dropping it sooner rather than later would have a
> beneficial effect on how much work we spend on shims/compat, complexity, and
> our ability to ship new features, as well as onboarding people who are
> interested in the project, but have no interest (or experience!) in Python
> 2.7.
Personally, I don't have this problem, but I'm certainly willing to believe
it's a bigger deal for others; especially others who perhaps have not even
learned Python 2 at this point.
> It is basically summed up by doing a feature freeze on an agreed-upon version
> of Twisted, that will be the last version released for 2.7. It would be
> abnormal in that it would get security fixes (our current policy is to only
> release them for current versions) and critical bugfixes, but would otherwise
> be frozen.
Here's my question about this:
Who will do this work?
Personally, I'm not willing to commit to this. I know from experience both on
Twisted and other projects that maintaining multiple release branches, even one
that's "maintenance only", requires at least one point-person for each branch
at all times (usually a "release manager"). And backporting fixes inevitably
gets harder and harder as the "maintenance" branch diverges from top-of-tree.
If I have time to work on Twisted in my increasingly scarce spare time, I want
it to be on something at least plausibly interesting, and manually backporting
manual fixes to an unmaintained py2 branch that I don't even use doesn't
qualify.
("But glyph", I hear you ask, "then why are you willing to write py2 code as it
is?". Well, hypothetical reader, it's because I find it easily an order of
magnitude easier to fix version discrepancies in the same change where they
creep in, and CI is yelling me about them, than it is to fix them in a big
tangled morass six months later with no idea which part of the code I'm
backporting is the issue.)
Do we have py2-only users who are willing to take ownership of this branch?
Specific people willing to sign up for this responsibility for the next... how
long? Three years? Five years?
So I'd rather be quite explicit that while we would not object to anyone
filling these roles, someone still needs to step forward and fill them, and I'm
not willing to commit the current team, such as it is, to work that I myself am
unwilling to do. If nobody does step forward we should not claim to have
security support for a dead / unmaintained branch.
> One of my rationales is that from some analysis of PyPI download statistics,
> the vast majority of Python 2 users are using old versions of Twisted, while
> nearly all our Python 3 users are on the latest version. As such, I believe
> freezing a version that will get security updates but no new features would
> not be a massive loss to those stuck on Python 2 for whatever reason.
I know that you detailed some of this on IRC, but: how old?
My sense would be that of course users stuck on py2 would have a more
conservative upgrade cadence than py3 users, but that doesn't mean they never
upgrade. How far behind are these py2 users, and does the curve suggest
they're catching up or are most twisted downloads just like, version 1.3 on
python 1.5.2 forever?
> Twisted's compatibility policy would still apply, ensuring that Python 2/3
> compatible software using Twisted would be able to use the older Twisted
> version on Python 2, and the newer version on Python 3, as you would usually
> expect.
We have 2 big blockers here right now that would prevent doing this as things
stand right now:
Twisted is not yet fully ported to Python 3, so there's no version where you
can use all of Twisted on Python 3. This picture is way, way smaller than it
has ever been, though - grab a module and start porting:
http://blog.habnab.it/twisted-depgraph/
<http://blog.habnab.it/twisted-depgraph/>
We still have Python 2 in production ourselves that requires Twisted;
specifically:
Trac and several of our ancillary utilities around it. Happily this does seem
to be fairly actively worked on: "opened 4 years ago, last modified 12 days
ago" https://trac.edgewall.org/ticket/12130
<https://trac.edgewall.org/ticket/12130>
Dogfood DNS: twisted.names doesn't work on python 3:
https://twistedmatrix.com/trac/ticket/9496
<https://twistedmatrix.com/trac/ticket/9496>
Our front-end webserver might work on pypy3, but we have yet to move it over.
Maybe that would be a good place to start?
If this proposal lights a fire under some folks to drive any of these projects
to completion, that would be great!
> You can find the proposal here, in this handy-dandy Google Doc:
> https://docs.google.com/document/d/1S4CGgZC09blLIdk3Zo7wBa75A9_JuuH_3akkyjN0lik/edit
>
> Comments are welcome, as well as which timeline seems reasonable.
Personally I feel like Option 1 is the most reasonable. We can't do option 3
because of the above blockers, and option 2 just seems random to me - why
commit to 4 months of additional maintenance beyond when py2 itself is EOL?
Maybe there's an option like, 1.5, where we de-support py2 at max(2020-01-01,
"the date at which we no longer have any py2 code in production ourselves")?
-g
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
