Thanks for your interest in working on Twisted this summer through Google Summer of Code! Here's an overview of the application process:
1. Get in touch and let us know that you're interested, by sending an e-mail to `twisted-gsoc@twistedmatrix.com` 1. Get familiar with the Twisted development process (see below). 1. Submit at least 1 patch to Twisted (don't worry, we're here to help if you need it!) 1. Create a <a href="https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#5._What_should_a_student_proposal_look" target="_blank">project proposal</a> with a Twisted mentor 1. Apply on the <a href="https://www.google-melange.com/gsoc/homepage/google/gsoc2013" target="_blank">Google Summer of Code web page</a> for the Python Software Foundation group, with the project proposal we created.
Switching to Formal Parsers
Twisted has lots of code for parsing protocols: turning a stream of bytes (e.g. an HTTP request) into Python structures and function calls. Unfortunately all of this parsing is ad-hoc, and manually written. This project would involve using the Parsley parsing framework (https://pypi.python.org/pypi/Parsley) to parse network protocols, replacing Twisted's code. Because Parsley is a work in progress, this would involve some amount of experimentation, and building proof-of-concepts.
What you would learn: Network protocols' structure, text parsing.
Coding Standard Enforcement
Every patch submitted to Twisted must go through code review. Part of this is test coverage, correctness and API design, but part is just mechanical: are lines formatted correctly, methods named correctly, etc.. Last summer one of the GSoC projects implemented a checker for Twisted's coding standard (http://launchpad.net/twistedchecker), which is now being run as part of Twisted's continuous integration (https://buildbot.twistedmatrix.com/builders/twistedchecker). There are still improvements and bug fixes to be made however.
What you'll learn: Text parsing, Python parsing and language edge cases, software development infrastructure.
Deferred Cancellation
Deferreds are Twisted's abstraction for an eventual result of a task. They are thus a good place to have a hook for cancelling the task, and they provide a cancellation API. However, many Twisted APIs that return Deferreds don't provide cancellation support. The project would involve adding cancellation support to as many APIs as possible (e.g. various protocol clients like HTTP, POP3, SMTP, etc. that are missing it), starting with easy cases and moving on to more difficult ones. You can read more about Deferred cancellation here and here.
What you'll learn: a good knowledge of event-driven programming, and a little bit about lots of different parts of Twisted.
Rewrite twisted.web.client.getPage using Agent
Twisted has two HTTP client APIs; the new one is Agent, the old one getPage based on a much less featureful HTTP implementation. Rewriting getPage to use Agent would allow old code to benefit from the features added in Agent (e.g. chunked encoding), while preserving backwards compatibility.
What you'll learn: how HTTP works, and the high-level APIs users expect.
Reactor Metrics and Monitoring Interface
The reactor runs lots of events; connectionMade, dataReceived, connectionLost, timed calls, and queued calls from callFromThread. But currently there's no tools to discover how long those events took, or what resources they consumed, so when one event makes your reactor get "stuck" you might not know which one it is without some manual instrumentation.
You could build a reporting protocol which would report timings and potentially other relevant status information on the reactor's activities to a client connected on an appropriate socket. For example: the longest, shortest, mean and median event times over a particular interval, and which objects and code were involved in the longest and shortest. (This would not necessarily involve a user interface, just the internal infrastructure necessary to extract and report this information to other tools which could make sense of it.)
Requirements: an understanding of event-driven programming, and some experience with monitoring or performance tools.
Debugging UI
Build a user interface (a GUI, or maybe even Web-based). The idea is to have a debugging user interface for running a Twisted process that shows existing listening ports and open connections, and allows you to view bytes flowing over the transports. This would look you look at a running Twisted program and see what was going on inside and what data was flowing through it. (Twisted currently includes a half-broken "gladereactor" that is a gtk-based half-finished implementation of this). You'll learn about Twisted's internals, and get to build an interesting user interface and present information in a useful way.
Requirements: In addition to Python, some knowledge of either GUI programming or Web programming.
Sphinx documentation
Finish converting our documentation from a custom format and set of tools that we maintain (Lore) to the Python community standard - RestructuredText (ReST) as used by http://sphinx.pocoo.org/. In particular, resolve all tickets in the [milestone:"Lore] milestone and then help transition the release process and twistedmatrix.com to Sphinx by participating in a release. You'll learn about releasing software, documentation tools, and maybe some data transformation (from HTML to RestructuredText).
Requirements: In addition to knowledge of Python, knowledge of HTML and perhaps ReST would be useful.
Don't break in other locales
Twisted currently has some bugs when used in certain non-English-configuration ("locales"), e.g. French. For example, date formatting might be wrong, or uppercase/lowercase conversion might work unexpectedly. As a first step you'd want to create a custom locale for Linux that was malicious about everything (e.g. lower-casing returns random unexpected bytes, dates are funky, etc.). This would be used to find places where Twisted is making US-centric assumptions, but would actually be a useful project for the Linux community in general. Then, fix resulting bugs in Twisted. Some relevant background material: http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html
Requirements: This is probably easier to do on Linux than on Windows, so some basic familiarity with Linux, and a computer configured to use it, in addition to knowledge of Python.
Before contributing to Twisted, please spend some time practicing the tools of open source development.
Here are some of the tools we use:
1. IRC 2. the Trac issue tracker 3. the svn revision control system 4. the diff and patch utilities
If you have not used IRC before, please go through this short tutorial on installing and using an IRC client:
Please familiarize yourself with how Twisted uses Trac by exploring the reports from this link: http://twistedmatrix.com/trac/report
With sufficient exploration you should be able to answer the following questions (you don't have to tell me the answers, just make sure you know how to find them):
1. What is the oldest open Twisted ticket? 2. How many tickets are currently waiting on review? How do we denote tickets waiting on a review (hint: look at the keyword) 3. Using the custom query page at http://twistedmatrix.com/trac/query, find out how many open tickets we have that have the "documentation" keyword.
If you have not used svn before, please go through the svn training mission at: http://openhatch.org/missions/svn
If you have not used diff and patch before, please go through the diff and patch training mission at: http://openhatch.org/missions/diffpatch
If you have any questions while going through this material, don't hesitate to ask for help in #twisted on IRC or on the twisted-python mailing list.
Once you've gone through this material, the next steps will be to:
1. Meet up on IRC (stop by the `#twisted` channel on Freenode) 2. Check out and explore the Twisted source code 3. Read a few parts of the Twisted core documentation and run some example Twisted scripts 4. Run the Twisted test suite - cd into the checkout folder and run "bin/trial twisted".
And then you'll be in great shape to start working on your first Twisted ticket. We'll suggest a first ticket when you get in touch over email; you'd want to fix it in your Twisted svn checkout, run `svn diff`, upload the resulting patch to the ticket and then add the "review" keyword to the ticket. This process is described in detail here: http://twistedmatrix.com/trac/wiki/TwistedDevelopment#SubmittingaPatch