State diagram of patch status, possible bug in apps/patchwork/utils.py

[Carl-Daniel Hailfinger]

Hi,

On 08.07.2009 04:58, Jeremy Kerr wrote:
> There's a little documentation in the doc/ directory, but not a whole 
> lot. I'd like to add some online help to patchwork though.
>   

I only found docs/INSTALL and docs/TODO. It seems I'm looking in the
wrong place. Any hints are appreciated.


> There's no expected flow; it's really up to the maintainers of the 
> project. It's also why the patch states are configurable.
>   

Great!

> However, this is generally what we do for powerpc:
> [...]
> Then the merge bundle is downloaded, and applied with a custom script, 
> which updates the patchwork states accordingly (using pwclient).
>   

That's certainly one possible mode of operation. For flashrom, we have
multiple maintainers who all commit to the central repository and I hope
to keep their workflow unchanged for minimal disturbance. Making
patchwork the central patch application gate certainly is a possibility
and I'll think about it. Please see my reply to point 5 for more details.


>> 3. apps/patchwork/models.py line 291 looks for the following regexp:
>> [...]
>>     
>
> I've just pushed a change for this. Had it sitting in my local tree for 
> a while :/
>   

Thanks.


>> 4. apps/patchwork/templatetags/syntax.py line 41ff is missing
>> Nacked-by.
>>     
>
> Fixed and pushed.
>   

Thanks.


>> 5. How can I automatically match commits against pending patches? We
>> use one centralized subversion repository and the mailing list gets a
>> commit mail for every commit. If matching committed patches
>> automatically against pending patches is not possible, can we have
>> patchwork parse replies to patches which usually say something like
>> "...comitted in r1234" or "thanks, r1234"?
>>     
>
> You can use the patch 'hash' for this. It's a bit hacky for now, but 
> still possible:
>
> $ python ./apps/patchwork/parse.py --hash < foo.patch
> 7951ad5e4f12f93adaced1718f713f6a70979dcd
>
> This hash is based on the content of the patch, minus stuff that's 
> likely to change (eg line numbers). You can then use this hash to match 
> a patch in patchwork:
>
> $ pwclient update -s Accepted -c <commit-ref> -h <hash>
>   

All committed flashrom patches are sent to the normal flashrom mailing
list, but the sender is special: It is always svn at flashrom.org (which
seems to be in contrast with git which has the author as sender of
commit mails AFAIK). Can the mail parser special case patches from that
address and not treat them as new patches, but rather extract the hash
from them and automatically set the patch state for the corresponding
patch in patchwork to "Accepted"?
That way, commit mails would automatically be matched against pending
patches and automatically update their status in patchwork with zero
effort from the committer.

Adding your suggestion above to a post-commit hook would probably work
as well. I need to investigate that alternative.

There's one additional special case: Commit mails may contain additional
Signed-off-by and Acked-by statements. Since the commit mails are not
part of the original thread, how can we add the commit message (and any
acks in there) to the original patch in patchwork?


>> 6. Some parts of patchwork seem to hardcode git usage. Is that just
>> because nobody had the time to add subversion support as well?
>>     
>
> Which bits? patchwork should be VCS-neutral - if there's anything that's 
> too specific to git, then I can look at making it work with svn too.
>   

apps/patchwork/bin/update-patchwork-status.py uses a few git commands.


>> 7. Possible bug in the unarchive action in apps/patchwork/utils.py,
>> patch follows:
>> [...]
>>     
> Thanks, applied.
>   

Thanks!

I am impressed with your fast and detailed response and think we can
certainly make patchwork handle our workflow well.


Regards,
Carl-Daniel

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