[Python-Dev] Automated testing of patches from bugs.python.org
olemis at gmail.com
Wed May 20 22:42:31 CEST 2015
On 5/19/15, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/19/2015 11:02 AM, Kushal Das wrote:
I'm not very familiar with python-dev development workflows .
Nonetheless I just wanted to mention something that proved to be
useful for me in the past .
>> With the help of CentOS project I am happy to announce an automated
>> system  to test patches from bugs.python.org. This can be fully
>> to test the patches whenever someone uploads a patch in the roundup, but
>> for now it accepts IRC commands on #python-dev channel. I worked on a
>> docker based prototype during sprints in PyCon.
>> How to use it?
>> 1. Join #python-dev on irc.freenode.net.
>> 2. Ask for test privilege from any one of kushal,Taggnostr,bitdancer
>> 3. They will issue a simple command. #add: YOUR_NICK_NAME
>> 4. You can then test by issuing the following command in the channel:
>> #test: BUGNUMBER
>> like #test: 21271
> What if there are multiple patches on the issue? Pick the latest?
> This is not correct if someone follows up a patch with a 2.7 backport,
> or if there are competing patches.
It is a fact that running automated tests for patches is a really
useful feature . Nevertheless , IMHO for this to succeed at large
scale there is a need to manage the content of patches themselves ,
the base version they were built upon , as well as their order should
they be stacked . My suggestion for you therefore is to use Hg patch
repositories _ as the starting point for your patch CI system .
Some of the benefits I could mention :
- triggering (patch) builds on commit via web hooks
- CI infrastructure needed turns out to be very
similar to the one setup for the main project
- Commands to work on patch queue repositories are easy to learn
- The possibility of editing series file is also useful for ignoring
some patches without removing their contents .
- halt if patch cannot be applied upon latest version
* ... but still be able to see it in action by checking out the
of the code base used to build it in first place .
- try the patch against different versions of the code base as it evolves
- fuzzy refresh
- version control for patches
- multiple branches
* which may be bound to tickets in many ways e.g. naming conventions
* ... particularly useful for competing patches .
There are a few black spots too . Patch repositories deal with the
diff of a diff , hence some operations applied upon patches (e.g.
merging) might be quite messy , Most of the time this is no big deal
The following are repositories I used while developing Apache
Bloodhound , during incubation and after it became a TLP . I'm
including them to illustrate branching and naming conventions (I used)
to keep track of tickets .
HTH , since this way the workflow would be tightly integrated with
Mercurial , as highlighted by Berker Peksağ in previous messages .
..  http://mercurial.selenic.com/wiki/MqTutorial
Olemis - @olemislc
Apache™ Bloodhound contributor
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
More information about the Python-Dev