On 5/19/15, Terry Reedy 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:
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 .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 .
..  http://mercurial.selenic.com/wiki/MqTutorial