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 16/05/13 08:16, Joseph S. Myers wrote:
> On Wed, 15 May 2013, David Miller wrote:
> 
>>> The GCC list has thousands of patches in it.  To be useful someone would 
>>> need to remove non-patches and reviewed patches promptly, to the extent it 
>>> can't do that automatically.
>>
>> Patchwork, as the web site several of us have given you the URL to
>> explains, knows what a patch looks like and does not track
>> non-patches.
> 
> The website appears to have very little information.  The "docs" link at 
> the top of <http://jk.ozlabs.org/projects/patchwork/> appears to have 
> nothing to do with patchwork at all.  There appears to be little 
> documentation in the patchwork source distribution either.  I can't tell 
> from either of those whether a patch sent in the thread discussing a 
> previous patch revision will be considered by patchwork as something new, 
> or as a comment on the previous version (and so not very visible if the 
> previous version has been marked as reviewed), for example.

>From what I have seen, it considers the new version of the patch as a
comment and updates the version of the patch it is tracking.  I can not
remember if it changes its status back to New.  Of course, that is
provided the new patch is sent in a reply and not a new thread.

> But I don't see anything indicating that it will automatically detect 
> whether patches are reviewed, meaning that for it to be more useful for 
> glibc than the list of thousands of patches for GCC, someone needs to be 
> maintaining the list of patches in the patchwork instance - marking 
> reviewed patches as such - so that if we want to clear the review backlog 
> as we approach a release freeze, patchwork does actually show the backlog 
> contents and not a huge pile of patches 90% of which were reviewed long 
> ago.

I have been using it for the Arch Linux package manager (pacman):
https://patchwork.archlinux.org/project/pacman/list/?state=*

There is no autodetection of anything.  When you review a patch, you
mark it as "Changes Requested".  When you commit a patch, you mark it as
"Accepted" and archive it.

It is all very manual.  However, it does allow me to keep track of all
the patches I have not reviewed, which has been good for a small
project.  It would require somebody to manage it if used in a bigger
project such as glibc or a concerted effort by reviewers/committers to
keep it updated.

Allan



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