This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up state on patchwork
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, libc-alpha at sourceware dot org, Florian Weimer <fweimer at redhat dot com>
- Date: Mon, 28 Sep 2015 10:02:26 -0400
- 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 09/25/2015 04:55 PM, Mike Frysinger 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.
What if you're on vacation? What if you're busy? The patchwork queue
is still really helpful to keep your list of patches you need to go
back to and resubmit.
What problem are we trying to solve here? I expect the patchwork queue
will simply grow forever, and that's fine. Aren't we always just looking
at the most recent submissions?
The only solid solution I can see is:
* Mark patches older than a year which are "New" with a special tag "Resubmit"
* Document that "Resubmit" means your patch is old and should be
retested and resubmitted.
* Annually mark older than a year patches which are "New" with "Resubmit."
I think reusing an existing state like Dropped or Rejected is only
going to cause confusion. It should be possible to understand exactly
which transformation was applied to your patches so you can undo that
e.g. New->Resubmit after a year. We should not loose any more state than
that IMO.
c.