[Qemu-devel] patchwork service.

[Qemu-devel] patchwork service.

[Jean-Christophe Dubois]

I know there is some discussion on how to get earlier feeback to people 
submitting patches.

It seems there already is a "patchwork" service available.

http://patchwork.ozlabs.org/project/qemu-devel/list/

But it is not used as the patch status is not updated for quite a few of them 
(even if they have been accepted/merged since then).

Re: [Qemu-devel] patchwork service.

[Anthony Liguori]

Jean-Christophe Dubois wrote:
> I know there is some discussion on how to get earlier feeback to people 
> submitting patches.
>
> It seems there already is a "patchwork" service available.
>
> http://patchwork.ozlabs.org/project/qemu-devel/list/
>
> But it is not used as the patch status is not updated for quite a few of them 
> (even if they have been accepted/merged since then).
>   

I looked at the patchwork tooling and it didn't seem to easily integrate 
into my work flow.  It seems to be designed with the idea that you use 
their tools to pull and manage patches.  I don't think those tools will 
scale to the volume of patches qemu-devel sees though.  Plus, there's no 
easy way to deal with the fact that other maintainers may not use it.  
Now there are a few thousand patches and trolling through would take ages.

Not really sure how to best proceed.  I'm open to suggestions.

Regards,

Anthony Liguori
>
>
>
>   

Re: [Qemu-devel] patchwork service.

[Carl-Daniel Hailfinger]

On 15.09.2009 00:50, Anthony Liguori wrote:
> Jean-Christophe Dubois wrote:
>> http://patchwork.ozlabs.org/project/qemu-devel/list/
>>
>> But it is not used as the patch status is not updated for quite a few
>> of them (even if they have been accepted/merged since then).  
>
> I looked at the patchwork tooling and it didn't seem to easily
> integrate into my work flow.  It seems to be designed with the idea
> that you use their tools to pull and manage patches.  I don't think
> those tools will scale to the volume of patches qemu-devel sees
> though.  Plus, there's no easy way to deal with the fact that other
> maintainers may not use it.  Now there are a few thousand patches and
> trolling through would take ages.

Note that there are scripts which can be placed in commit hooks and
automatically mark patches as applied if they were not changed between
submission and applying.
There are also scripts which walk the commit history between commit A
and commit B and run the commit hook script for every commit in between.

> Not really sure how to best proceed.  I'm open to suggestions.

flashrom and coreboot are doing pretty well with the patchwork commit
hooks. Patches which were changed between sending and applying need
manual care, and patch versioning (improved new editions of a patch) is
not handled automatically yet. Still, having people invest a few minutes
daily to check if some patches look like they've been superseded by new
versions helps us keep the patchwork database clean.

All of this is done without incorporating patchwork into the workflow,
so patchwork is essentially just a public patch management/tracking tool
which can help us remember those patches which slipped though the cracks.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] patchwork service.

[Anthony Liguori]

Carl-Daniel Hailfinger wrote:
> On 15.09.2009 00:50, Anthony Liguori wrote:
>   
>> Jean-Christophe Dubois wrote:
>>     
>>> http://patchwork.ozlabs.org/project/qemu-devel/list/
>>>
>>> But it is not used as the patch status is not updated for quite a few
>>> of them (even if they have been accepted/merged since then).  
>>>       
>> I looked at the patchwork tooling and it didn't seem to easily
>> integrate into my work flow.  It seems to be designed with the idea
>> that you use their tools to pull and manage patches.  I don't think
>> those tools will scale to the volume of patches qemu-devel sees
>> though.  Plus, there's no easy way to deal with the fact that other
>> maintainers may not use it.  Now there are a few thousand patches and
>> trolling through would take ages.
>>     
>
> Note that there are scripts which can be placed in commit hooks and
> automatically mark patches as applied if they were not changed between
> submission and applying.
>   

Can you point me in their direction?  I'll take a look

Regards,

Anthony Liguori

Re: [Qemu-devel] patchwork service.

[Michael S. Tsirkin]

On Tue, Sep 15, 2009 at 02:38:56AM +0200, Carl-Daniel Hailfinger wrote:
> On 15.09.2009 00:50, Anthony Liguori wrote:
> > Jean-Christophe Dubois wrote:
> >> http://patchwork.ozlabs.org/project/qemu-devel/list/
> >>
> >> But it is not used as the patch status is not updated for quite a few
> >> of them (even if they have been accepted/merged since then).  
> >
> > I looked at the patchwork tooling and it didn't seem to easily
> > integrate into my work flow.  It seems to be designed with the idea
> > that you use their tools to pull and manage patches.  I don't think
> > those tools will scale to the volume of patches qemu-devel sees
> > though.  Plus, there's no easy way to deal with the fact that other
> > maintainers may not use it.  Now there are a few thousand patches and
> > trolling through would take ages.
> 
> Note that there are scripts which can be placed in commit hooks and
> automatically mark patches as applied if they were not changed between
> submission and applying.
> There are also scripts which walk the commit history between commit A
> and commit B and run the commit hook script for every commit in between.

Could you post a link to these scripts please?

-- 
MST

Re: [Qemu-devel] patchwork service.

[Carl-Daniel Hailfinger]

[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]

[Adding the patchwork mailing list to CC:]

On 06.10.2009 18:38, Michael S. Tsirkin wrote:
> On Tue, Sep 15, 2009 at 02:38:56AM +0200, Carl-Daniel Hailfinger wrote:
>   
>> On 15.09.2009 00:50, Anthony Liguori wrote:
>>     
>>> Jean-Christophe Dubois wrote:
>>>       
>>>> http://patchwork.ozlabs.org/project/qemu-devel/list/
>>>>
>>>> But it is not used as the patch status is not updated for quite a few
>>>> of them (even if they have been accepted/merged since then).  
>>>>         
>>> I looked at the patchwork tooling and it didn't seem to easily
>>> integrate into my work flow.  It seems to be designed with the idea
>>> that you use their tools to pull and manage patches.  I don't think
>>> those tools will scale to the volume of patches qemu-devel sees
>>> though.  Plus, there's no easy way to deal with the fact that other
>>> maintainers may not use it.  Now there are a few thousand patches and
>>> trolling through would take ages.
>>>       
>> Note that there are scripts which can be placed in commit hooks and
>> automatically mark patches as applied if they were not changed between
>> submission and applying.
>> There are also scripts which walk the commit history between commit A
>> and commit B and run the commit hook script for every commit in between.
>>     
>
> Could you post a link to these scripts please?
>   

The scripts I saw were git-based, but I can't remember where I found
them. Maybe someone on the patchwork list knows.

I have attached my personal script which is centered around flashrom and
its svn repo.
Please note that the two svn invocations are intentional. The first one
retrieves a patch designed to be applied with patch -p0, the second one
retrieves the same patch, but from a higher directory so you have to
apply with -p1. AFAIK patchwork generates a hash which normalizes the
first component of the path if it is a directory, so the hash will be
identical for manual diffs from a level above the base directory and git
diffs, but manual diffs inside the base directory will have a different
hash. Generating both styles of patches from the repo increases matching
reliability.
You will have to change the lines which calculate hashcand to retrieve
the patches from git instead.
The script expects a correct ~/.pwclientrc with your password.

For flashrom, I just run
# update-patchwork 743
if I want to mark revision 743 as committed. You can look at the
corresponding patchwork page here:
http://patchwork.coreboot.org/patch/323/ . Note "State Accepted" and
"Commit r743" at the beginning of the page.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/


[-- Attachment #2: update-patchwork --]
[-- Type: text/plain, Size: 667 bytes --]

#!/bin/bash
test -z "$1" && { echo "No revision provided."; exit 1; }
revision="$1"
hashcand=$(svn diff -c $revision svn://coreboot.org/flashrom/trunk/|python /sources/tmptrees/patchwork/apps/patchwork/parser.py --hash)
/sources/tmptrees/patchwork/apps/patchwork/bin/pwclient update -s Accepted -c r$revision -h $hashcand && { echo "done"; exit 0; }
echo
hashcand=$(svn diff -c $revision svn://coreboot.org/flashrom/|python /sources/tmptrees/patchwork/apps/patchwork/parser.py --hash)
/sources/tmptrees/patchwork/apps/patchwork/bin/pwclient update -s Accepted -c r$revision -h $hashcand && { echo "done"; exit 0; }
echo "No matching patch in patchwork found."
exit 1

Re: [Qemu-devel] patchwork service.

[Jean-Christophe Dubois]

On Tuesday 15 September 2009 00:50:52 Anthony Liguori wrote:
> Jean-Christophe Dubois wrote:
> > I know there is some discussion on how to get earlier feeback to people
> > submitting patches.
> >
> > It seems there already is a "patchwork" service available.
> >
> > http://patchwork.ozlabs.org/project/qemu-devel/list/
> >
> > But it is not used as the patch status is not updated for quite a few of
> > them (even if they have been accepted/merged since then).
>
> I looked at the patchwork tooling and it didn't seem to easily integrate
> into my work flow.  It seems to be designed with the idea that you use
> their tools to pull and manage patches.  I don't think those tools will
> scale to the volume of patches qemu-devel sees though.

The linux netdev project is using it and this is also a high traffic mailing 
list. So if it works for them it might also work here.

http://patchwork.ozlabs.org/project/netdev/list/

> Plus, there's no
> easy way to deal with the fact that other maintainers may not use it.

Well, I don't know about this. It certainly need to be an agreement between 
the qemu maintainers on using this tool.

> Now there are a few thousand patches and trolling through would take ages.

Well I guess there is an initial cost to it, but hopefully it might help in 
the long term.

>
> Not really sure how to best proceed.  I'm open to suggestions.
>
> Regards,
>
> Anthony Liguori