This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Tracking patch pings
- From: Allan McRae <allan at archlinux dot org>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org, Carlos O'Donell <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 16 May 2013 12:57:09 +1000
- Subject: Re: Tracking patch pings
- References: <Pine dot LNX dot 4 dot 64 dot 1305152117141 dot 21321 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1305160002490 dot 3122 at digraph dot polyomino dot org dot uk> <51944267 dot 7040900 at redhat dot com> <201305152240 dot 35526 dot vapier at gentoo dot org>
On 16/05/13 12:40, Mike Frysinger wrote:
> On Wednesday 15 May 2013 22:20:23 Carlos O'Donell wrote:
>> On 05/15/2013 08:52 PM, Joseph S. Myers wrote:
>>>> What benefit do people see in patchwork over an unstructured
>>>> wiki list and heavily structured feature bug?
>>>
>>> The benefit is that it fails safe - if a patch is submitted and noone
>>> follows any special process, it's automatically tracked until someone
>>> says it no longer needs tracking - and imposes no extra work on
>>> reviewers, and doesn't require any extra work from submitters either. I
>>> think you'll need someone who tries to keep the patchwork data clean,
>>> but you can also encourage contributors to do so themselves for their
>>> own patches.
>>
>> I like the fail safe aspect.
>
> that covers patchwork
>
>> What we need is to tie patchwork in the git commit emails and let it
>> close out patches as they get checked into git?
>
> if our git commits retained the subject line (ala `git am`), then a git hook
> might be able to coordinate with patchwork and update its status. they
> provide a command line patchwork client.
While looking for that client (still looking...) I noticed this in thier
git repo:
post-receive.hook
# Git post-receive hook to update Patchwork patches after Git pushes
Looks interesting!