This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tracking patch pings


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.

> What do we need to do to avoid having a human in the loop?

my biggest gripe with patchwork is that there is no command interface via the 
list.  it'd be nice that when you respond on the list to say you've merged 
something, you could also do:
X-Patchwork-Set-Status: Accepted

> Like getting git commit hooks that update bugizlla bugs.

that'd be nice to have regardless of patch tracking
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]