[Twisted-Python] Twisted 17.1 Release Announcement

[Jean-Paul Calderone]

On Wed, Feb 15, 2017 at 3:39 AM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Feb 11, 2017, at 5:54 PM, Jean-Paul Calderone <
> exarkun at twistedmatrix.com> wrote:
>
> On Sat, Feb 11, 2017 at 5:03 AM, Amber Hawkie Brown <
> hawkowl at atleastfornow.net> wrote:
>
>> On behalf of Twisted Matrix Laboratories, I am honoured to announce the
>> release of Twisted 17.1!
>>
>> The highlights of this release are:
>>
>> - twisted.web.client.Agent now supports IPv6! It's also now the primary
>> web client in Twisted, with twisted.web.client.getPage being deprecated in
>> favour of it and Treq.
>> - twisted.web.server has had many cleanups revolving around timing out
>> inactive clients.
>> - twisted.internet.ssl.CertificateOptions has had its `method` argument
>> deprecated, in favour of the new raiseMinimumTo, lowerMaximumSecurityTo,
>> and insecurelyLowerMinimumTo arguments, which take TLSVersion arguments.
>> This allows you to better give a range of versions of TLS you wish to
>> negotiate, rather than forcing yourself to any one version.
>> - twisted.internet.ssl.CertificateOptions will use OpenSSL's
>> MODE_RELEASE_BUFFERS, which will let it free unused memory that was held by
>> idle TLS connections.
>> - You can now call the new twist runner with `python -m twisted`.
>> - twisted.conch.ssh now has some ECDH key exchange support and supports
>> `hmac-sha2-384`.
>> - Better Unicode support in twisted.internet.reactor.spawnProcess,
>> especially on Windows on Python 3.6.
>> - More Python 3 porting in Conch, and more under-the-hood changes to
>> facilitate a Twisted-wide jump to new-style classes only on Python 2 in
>> 2018/2019. This release has also been tested on Python 3.6 on Linux.
>> - Lots of deprecated code removals, to make a sleeker, less confusing
>> Twisted.
>> - 60+ closed tickets.
>>
>> For more information, check the NEWS file (link provided below).
>>
>> You can find the downloads at <https://pypi.python.org/pypi/Twisted> (or
>> alternatively <http://twistedmatrix.com/trac/wiki/Downloads>). The NEWS
>> file is also available at <https://github.com/twisted/tw
>> isted/blob/twisted-17.1.0/NEWS>.
>>
>> Many thanks to everyone who had a part in this release - the supporters
>> of the Twisted Software Foundation, the developers who contributed code as
>> well as documentation, and all the people building great things with
>> Twisted!
>>
>>
> Thanks all!  Great to see the troubles of 16.7 mostly behind us.
>
>
> Yes, thanks!  Lots of good stuff in this release!
>
> I do hope there will be at 17.1.1 soon for <https://twistedmatrix.com/
> trac/ticket/9031> and particularly <https://twistedmatrix.com/
> trac/ticket/9032>.
>
>
> This is a little outside the normal process, but I added a milestone for
> these just so we have a thing to track when they're fixed and we should
> roll them up (and in case anything new appears):
>
> https://twistedmatrix.com/trac/milestone/17.1.1
>
> Something I should note about these regressions; they showed up as soon as
> Mimic upgraded its dependency: https://github.
> com/rackerlabs/mimic/pull/734
>
> This suggests to me that we really ought to have a more "active" phase of
> the release process where someone - let's say, the reviewer of the release
> ticket - goes out to check a select list of other projects' smoke tests to
> ensure that the prerelease is at least passing their CI.  For example, I
> would normally have tested Mimic myself, but I was out of commission with a
> nasty flu-like thing for a good chunk of the prerelease period, but since I
> happened to miss that window, well-known projects (heck, treq has its own
> tests for .testing, and those broke, and it's in the twisted org!) managed
> to break without getting noticed.
>

I wonder about the details of how treq's failures went unnoticed.  Is
development sufficiently inactive that no one looked at CI between the
breakage and the release?  Wasn't that a period of several months?  Or does
it have a Twisted trunk at HEAD build that none of the contributors really pay
attention to?

If the problem is attention, maybe some kind of alerting could be set up so
the folks who are actually working on Twisted have a direct feed of
information that might be related to that work creating regressions?  I
know there are problems with false positives from CI but the dial for
information flow seems to be set a bit too low right now.  Maybe turning it
up for a while and then re-evaluating makes sense.


> So, while it would be good if user projects reported breakages, we should
> be checking at least the *most* obvious parts of the integration
> ecosystem ourselves as part of the release process.
>
>
All other things being equal, it would be better to learn about the
breakage at the time of the breakage rather than at release time (for the
usual reasons).  So I think something like a mailing list for external CI
failures against Twisted trunk at HEAD is a better thing to try than telling
the RM to go look at a bunch of CIs.

Maybe we could even double down on this and host the new list solely on
txlists? :)

Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20170215/5cdbc79a/attachment-0002.html>