SoC 2007 Application

Project Title

Patch verification system for Python


The goal of this project is to provide a straightforward way to test patches from the Python bug/patch tracker on SourceForge (soon to be migrated to Roundup). This system will test patches and generate reports automatically, giving feedback only a few minutes after patch submission. Both sides of the patching process will benefit — the patch submitter can find out and fix his mistakes much faster, while Python maintainers are given a solid base for a patch review. Once in place, the system will make the process of accepting patches less tedious and much more productive.


For each new patch that appears on Python tracker the system will download it, check out the latest Python sources, patch them with the given diff and build the whole distribution. Once we have a working binary and libraries in place the system will run the automated tests shipped with Python. Results of a test run combined with the results of the patch application and build warnings/errors will be stored in a database for further inspection. Once the system proves its reliability automatic reporting capabilities can be added, including a detailed patch report as a comment on the tracker or an e-mail to the author and/or developer assigned to this patch. This report will include things like:

  • Patch conformance to common requirements, e.g. is it in a unified diff format. System will detect such mistakes and report them, but will try to work around them, so a build can be made nevertheless.
  • Whether the patch touched the documentation files or test cases.
  • PEP8 style conformance checking of added and modified lines (applies only to stdlib changes, although style checking C code may be included as well).
  • Build warnings split by build step (configuration/building) and by context (extensions), with flexible search and filter capabilities.
  • Unit test warnings and errors.

The system will try hard to complete each of the building steps, but upon error will gracefully log detailed error information and stop the whole process.

The system will be implemented as a set of Python scripts used on different levels: from build automation through collecting and storing logs up to a web interface. Builds will be done on operating systems running via VMWare, so every build will be run on the same pristine system, excluding a possibility of build clashes. A special effort will be made to make the system as reliable and predictable as possible. Specifically, along with the system code, I will develop a rich set of unit and functional tests. Where applicable, code will be based on existing and stable solutions – one of the foundations will surely include buildbot as deployed in Pybots architecture.


During interim period (April 11th – May 28th) I will work towards preparing a functional specification of the system. Working with the core developers who will be interested in contributing ideas I will try to gather information on what specific features would be essential for the success of this project. We will hopefully discuss both technical and psychological (or even political) aspects of introducing this system. In particular possible reliability problems have to be discovered and analyzed, so that I can be prepared to build a system whose reports will be trusted.

On May 28th implementation begins. First efforts will be put toward setting up a solid backend for the whole system. In this 6-week period I will set up a VMWare box, configure it and write all required code to automate the whole build process, from checking tracker status to putting data into a database. By July 9th we should have a working build system with a very simplistic interface. After that, another 6 weeks will be used to develop a friendly web interface for that system. That includes both dynamic configuration of a system and extensive reports and data visualization.

With a bit of luck project will be ready to use by core developers by August 20th. From there I hope to involve other developers into maintaining and improving the system.


My name is Michał Kwiatkowski and I study Computer Science at Gdansk University of Technology, Poland. My first programming experience date back to times I was about 9 years old and was coding simple applications in BASIC on C=64. I’ve got seriously involved into programming during my high school years. Since then I learned C, Perl, assembly, Python, Ruby and a bit of JavaScript and Lisp, gaining knowledge from its philosophies and communities. I have been interested in open source for about 3 years now. Currently I’m involved mostly in Python testing community, gathered around TIP mailing list and nose. I also make Rails applications for fun and profit. Last year’s summer my Cheesecake enhancements project was chosen for Summer of Code by PSF and was successfully completed. Effects of my work can be seen in the Cheesecake project itself as well as in Cheesecake service.


Both Grig Gheorghiu and Titus Brown will participate in mentoring this project.

Contact information

Name: Michał Kwiatkowski
Jabber ID:

3 responses

19 04 2007
Accepted to Summer of Code 2007! « Mousebender

[…] SoC 2007 Application […]

28 05 2007
PVS architecture draft « Mousebender

[…] SoC 2007 Application […]

30 07 2007
PVS update « Mousebender

[…] SoC 2007 Application […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: