This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up state on patchwork
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 25 Sep 2015 14:20:21 -0700
- Subject: Re: Clean up state on patchwork
- Authentication-results: sourceware.org; auth=none
- References: <1442410615 dot 2348 dot 19 dot camel at reserved-bit dot com> <alpine dot DEB dot 2 dot 10 dot 1509172302350 dot 2455 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1509252025170 dot 1123 at digraph dot polyomino dot org dot uk> <20150925205526 dot GA1535 at vapier dot lan>
On Fri, Sep 25, 2015 at 1:55 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 25 Sep 2015 20:36, Joseph Myers wrote:
>> I've now cleaned up patchwork state for submitters with only a few patches
>> in the alphabetical ranges I previously skipped. The following submitters
>> still have large numbers of patches which I have not attempted to go
>> through and their patchwork entries still need cleaning up to make sure
>> that only the most recent versions of uncommitted patches are listed, with
>> others being marked as superseded / committed / ....
>>
>> Alexandre Oliva
>> Andreas Schwab
>> Andrew Pinski
>> Florian Weimer
>> H.J. Lu
>> Ondrej Bilka
>> Paul Pluzhnikov
>> Stefan Liebler
>> Torvald Riegel
>>
>> Would someone like to volunteer to clean up patchwork state for those
>> submitters, or to do the next general cleanup of all pending patches in
>> patchwork (say, once we have a system for most commits no longer to need
>> to update ChangeLog or NEWS, and for automatically marking committed
>> patchwork entries for patches whose git-patch-id corresponds with that of
>> a commit, going through all the entries at that time to remove past
>> entries that are committed or superseded)?
>
> i think they all have commit access to the glibc repo in which case they
> should have access to the patchwork glibc instance in which case they
> should be managing their patches themselves ? if we can't get them to
> do so, then we could just assign all patches to the person submitting
> it and marked them as dropped ? then it's back on them to make sure
> their patches get merged.
> -mike
How do I manage my patches? I have been pinging my patches
for weeks with no luck.
--
H.J.