On 5/19/15, Terry Reedy <tjre...@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:
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
