[Python-Dev] Automated testing of patches from bugs.python.org

[Olemis Lang]

On 5/19/15, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/19/2015 11:02 AM, Kushal Das wrote:
>> Hi,
>>

Hi !

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 [1] to test patches from bugs.python.org. This can be fully
>> automated
>> 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 [1]_ 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
right version
      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
though .

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 .

https://bitbucket.org/olemis/bloodhound-incubator-mq/
https://bitbucket.org/olemis/bloodhound-mq

HTH , since this way the workflow would be tightly integrated with
Mercurial , as highlighted by Berker Peksağ in previous messages .

.. [1] http://mercurial.selenic.com/wiki/MqTutorial

-- 
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: