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: Clean up state on patchwork


On 28 Sep 2015 13:36, Carlos O'Donell wrote:
> On 09/28/2015 11:43 AM, Joseph Myers wrote:
> >> will simply grow forever, and that's fine. Aren't we always just looking
> > 
> > It should only grow forever because of patches blocked on something other 
> > than review.  For example: patches needing the submitter to make required 
> > changes (though for inexperienced submitters, it would be helpful for more 
> > experienced developers to pick up such changes as needed if the submitter 
> > appears to have stopped working on the change); patches needing copyright 
> > assignment; patches depending on changes to an external component such as 
> > the Linux kernel; patches requiring the submitter to help lead discussion 
> > to consensus (though if it seems the answer is likely to be that the 
> > proposed feature isn't wanted at all, other people could usefully try to 
> > lead the discussion to that conclusion so the patch can be marked 
> > rejected).
> 
> This is only true if we actually have the resources capable of handling
> the volume of patches submitted? Which I surmise that at present we don't
> otherwise the patch queue would be going down.

from time to time i flip through the backlog and try to focus on the one-offs.
the excessive patches that have been superseded or submitted but not cleaned up
makes this difficult.  to the point where i probably give up simply because i
couldn't easily locate a patch that is actually unreviewed.

if patchwork is going to fill up with patches that have been reviewed/resolved
but not had their status updated, then it seems like kind of a waste of time, at
least for my use case.
-mike

Attachment: signature.asc
Description: Digital signature


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