This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Tracking patch pings
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 15 May 2013 22:20:23 -0400
- 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> <51941F6A dot 90601 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1305160002490 dot 3122 at digraph dot polyomino dot org dot uk>
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.
I like that discussions continue on list.
> So, if someone is willing to try to keep the patchwork data clean for a
> while, I think we should try patchwork. That does not exclude also using
> other tools.
Yet another job for someone we don't have to spare.
What we need is to tie patchwork in the git commit emails and let it
close out patches as they get checked into git?
What do we need to do to avoid having a human in the loop?
All the data is there, I'd rather work on automation than manual drudgery.
Like getting git commit hooks that update bugizlla bugs.
I think trying patchwork might be useful... with some more automation.
Cheers,
Carlos.