It's been a good weekend for the Twisted ecosystem! Despite spending rather more time on email than is usual for a weekend, I've been enjoying the mailing list activity so thanks to everyone for your contributions.
We had a good chat on IRC about some potential ways to increase contribution to the project. (I'll let the authors of these proposals raise them themselves, if they want to bring it to the broader forum of this list.) These proposals largely focused on structural issues with the way the project is maintained or the way the code is organized.
However, we have relatively few people who do much in the way of social organizing of Twisted and its constellation of ancillary projects. We have ad-hoc presences at a few regional conferences, a sometimes presence at the PyCon sprints (which, unfortunately, I don't think I'll be able to make this year).
One thing I'd like to propose I think would really help us get more engagement with the project and the ecosystem, possibly in addition to and in concert with some of the aforementioned structural/technical changes, is some dedicated, intentional social organization, particularly of our distributed online community.
Hackathons and sprints (which have probably provoked the majority of Twisted's development over the years) are not a lot more than "let's get together and do X at Y time". They can be organized online as well as in person. Still, a successful sprint requires someone to thoughtfully select variables X and Y and then effectively communicate about the event, both to people already involved in the project and also to potential audiences of newcomers. This involves finding students looking for projects to learn on, and finding users who might want get bugs that they have encountered fixed; in other words, "outreach".
It also involves some amount of celebrating accomplishments that come out of these events, to build enthusiasm for the next one. (If you've been organizing local events that we're not aware of, it would be great to hear about them!)
So I'd like to encourage anyone who might be wondering what they can do to contribute to the project but find the prospect of debugging IMAP serialization or use-after-free IO completion port debugging to be bewildering, "online sprint organizing" is a potentially very rich seam to mine for potential contributions.
If you are interested in trying to do this but need access to any Twisted resources in support of doing this - the main ones I can think of being our Twitter (https://twitter.com/twistedmatrix <https://twitter.com/twistedmatrix>) or Blogger (https://labs.twistedmatrix.com <https://labs.twistedmatrix.com/>) accounts - just let me know and I'd be happy to provide access.
Unless I'm missing something, Deferred.addTimeout is really unhelpful in
terms on providing context about *what* timed out.
TimeoutError(<some number>, 'Deferred') just isn't that useful.
How come addTimeout doesn't let you specify a textual reason, or
otherwise provide some context about the timeout?
Am I missing something obvious here?
I was just working on the documentation to fix Trac bug #5533, but I
have a question about intent. Right now, prepath and postpath are
undocumented; as best as I can tell, though, they are intended to be
public. Question is, are they part of the IRequest interface, or only of
the Request implementation?
(There aren't any other implementations of IRequest in Twisted, so I
suppose it's a little bit academic.)
It seems to me that they should be on IRequest, since IRequest already
has methods like prePathURL() which depend on the information in
prepath/postpath. Leaving these attributes off of IRequest wouldn't
provide any more flexibility to implementers of the interface, and
postpath in particular is very useful to people writing render methods.
Hello from PyCascades! Straight from the Pacific North-West, a new
Twisted release candidate!
In this release, there is:
- twisted.web.client.HostnameCachingHTTPSPolicy was added as a new
contextFactory option. This reduces the performance overhead for making
many TLS connections to the same host.
- twisted.conch.ssh.keys can now read private keys in the new
"openssh-key-v1" format, introduced in OpenSSH 6.5 and made the default
in OpenSSH 7.8.
- The sample code in the "Twisted Web In 60 Seconds" tutorial runs on
- DeferredLock and DeferredSemaphore can be used as asynchronous context
managers on Python 3.5+.
- twisted.internet.ssl.CertificateOptions now uses 32 random bytes
instead of an MD5 hash for the ssl session identifier context.
- twisted.python.failure.Failure.getTracebackObject now returns
traceback objects whose frames can be passed into traceback.print_stack
for better debugging of where the exception came from.
- Much more! 20+ tickets closed overall.
You can get the tarball and the NEWS file at
https://twistedmatrix.com/Releases/rc/19.2.0rc1/ , or you can try it out
python -m pip install Twisted==19.2.0rc1
Please test it, and let me know how your applications fare, good or bad!
If nothing comes up, 19.2 will release in a week.
Amber Brown (hawkowl)
Thanks to our long-suffering contributors Adi Roiban and Kyle Altendorf, we now have macOS builds running on circleCI! Supposedly we have sufficient resources to actually run all our builds, too, without running out of CI juice before the end of each month :-).
As such, I've changed our repository configuration to drop the old, somewhat outdated macOS buildbot, and replace it with the Circle CI infrastructure which should cover that platform.
With this change, none of the buildbot builders define our gating-to-trunk continuous integration. This is a great thing for the project, as it means external contributors will be able to get a "this is acceptable to merge" green checkmark without ./admin/pr_as_branch or any other similar repo:write-person-requiring shenanigans.
However, it also means that we are now spending a not-insignificant amount of contributor time maintaining a farm of machines that do tons of continuous integration work, which may not really be telling us anything interesting about Twisted's quality or correctness. I think it might be worth considering decommissioning buildbot.twistedmatrix.com <http://buildbot.twistedmatrix.com/> entirely, unless some of the vendors of the platforms and kernels covered there would like to step up to do some maintenance themselves. It's been a decade or so since Twisted was spotting regular regressions in Linux, FreeBSD or Darwin, so I think this style of build infrastructure may be a relic of a bygone era.
For my part, I probably will start doing any contributions on my own fork, since that will mean I don't have to constantly kick random spurious RHEL7 buildbot failures to avoid getting a red "X" on my PRs.
Furthermore, if we decom'd buildbot as software infrastructure, we'd still have a significant amount of cloud / hardware resources we could potentially throw at *other* problems facing the project which cloud CI doesn't cover as well, like SpeedCenter.
So, do folks have any strong feelings, or would anyone like to volunteer to help with some aspect of this? As always: we don't have enough folks to keep up with the operational demands of twistedmatrix.com <http://twistedmatrix.com/>, so if you want to dev some ops or ops some infra, please speak up :).