Re: Clean up state on patchwork

[Mike Frysinger <vapier at gentoo dot org>]

On 28 Sep 2015 10:02, Carlos O'Donell wrote:
> 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.

my proposal doesn't prevent that.  perform a search where the owner is you and
the state is set to dropped.

> 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?

people aren't cleaning up their own patches they've posted, and some of those
lists are not insignificant.  it makes it harder to go through patches that have
actually been missed.  it also makes it much harder the further back you go 
which i think is what patchwork is supposed to be helping with -- not dropping
patches from random people.

> 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.

i think this is where the disconnect is.  what do you think "dropped" means ?
imo, my proposal is using "dropped" for its intended use case: patches that
appear to have been dropped and need review wrt their status.  by assigning
them to the submitter (who has access already), we're clearing out the large
community sources so it's easier to focus on those.
-mike

Attachment: signature.asc
Description: Digital signature