[RFC] Archive old patches on patchwork?

[RFC] Archive old patches on patchwork?

[Siddhesh Poyarekar]

Hi,

Since there is little chance that anyone is going to walk through the 
patchwork state and review very old patches, can we archive patches from 
2019 and earlier on patchwork?  That will clean up the slate somewhat 
and make patchwork a bit more usable.

I ran a script today to close off patches that have the exact same diff 
in git, so the list is smaller by about ~800, but there's still ~6k more 
to go and most of those will never see the light of day.

The end goal for me is to get the patchwork instance to a point that it 
is actually reasonable to have more automation to close off applied 
patches and maybe even close off patches that don't apply anymore.  That 
means that we will be trying to emulate what gitlab does and maybe at 
that point we need to ask ourselves if we're better off putting in a 
gitlab instance instead :)

Siddhesh

Re: [RFC] Archive old patches on patchwork?

[Carlos O'Donell]

On 11/19/20 7:43 AM, Siddhesh Poyarekar wrote:
> Since there is little chance that anyone is going to walk through the
> patchwork state and review very old patches, can we archive patches
> from 2019 and earlier on patchwork?  That will clean up the slate
> somewhat and make patchwork a bit more usable.
> 
> I ran a script today to close off patches that have the exact same
> diff in git, so the list is smaller by about ~800, but there's still
> ~6k more to go and most of those will never see the light of day.
> 
> The end goal for me is to get the patchwork instance to a point that
> it is actually reasonable to have more automation to close off
> applied patches and maybe even close off patches that don't apply
> anymore.  That means that we will be trying to emulate what gitlab
> does and maybe at that point we need to ask ourselves if we're better
> off putting in a gitlab instance instead :)

I suggest archiving old patches from 2018 and earlier as a start.

I also want to start an open public patch review as discussed in my
GNU Tools Cauldron BoF for glibc.

-- 
Cheers,
Carlos.

Re: [RFC] Archive old patches on patchwork?

[Siddhesh Poyarekar]

On 11/19/20 9:45 PM, Carlos O'Donell wrote:
> I suggest archiving old patches from 2018 and earlier as a start.

The backlog is now down to ~2300 patches.  I suppose another check I 
could do is to try applying patches to the tree and mark those that 
don't apply as 'Changes Requested' and email submitters about it.

One issue I haven't solved yet is that of marking older patches as 
obsolete if an updated version is available.  I'm open to ideas or 
volunteers to help me do this and hopefully automate it.

> I also want to start an open public patch review as discussed in my
> GNU Tools Cauldron BoF for glibc.

+1

Siddhesh

Re: [RFC] Archive old patches on patchwork?

[DJ Delorie]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> I suppose another check I could do is to try applying patches to the
> tree and mark those that don't apply as 'Changes Requested' and email
> submitters about it.

Carlos and I had discussed this in the past... It's the kind of thing
that can (should) be automated via some sort of bot - does the patch set
apply cleanly to master?  Does master still build?  Does the patch meet
our coding standards?  Some of these boiler-plate tests should be
automated and the patchwork data updated accordingly.

Re: [RFC] Archive old patches on patchwork?

[Girish Joshi]

Hi Siddhesh,

On Fri, Nov 20, 2020 at 8:08 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> One issue I haven't solved yet is that of marking older patches as
> obsolete if an updated version is available.  I'm open to ideas or
> volunteers to help me do this and hopefully automate it.

I would like to volunteer for this.

Girish Joshi
girishjoshi.io

Re: [RFC] Archive old patches on patchwork?

[Siddhesh Poyarekar]

On 11/20/20 9:12 AM, Girish Joshi wrote:
> On Fri, Nov 20, 2020 at 8:08 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>> One issue I haven't solved yet is that of marking older patches as
>> obsolete if an updated version is available.  I'm open to ideas or
>> volunteers to help me do this and hopefully automate it.
> 
> I would like to volunteer for this.

Awesome, thanks!  Please create an account on patchwork.sourceware.org 
and ask me offline to get you added to the glibc project so that you can 
edit patch status.

Siddhesh

Re: [RFC] Archive old patches on patchwork?

[Siddhesh Poyarekar]

On 11/20/20 8:44 AM, DJ Delorie wrote:
> Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>> I suppose another check I could do is to try applying patches to the
>> tree and mark those that don't apply as 'Changes Requested' and email
>> submitters about it.
> 
> Carlos and I had discussed this in the past... It's the kind of thing
> that can (should) be automated via some sort of bot - does the patch set
> apply cleanly to master?  Does master still build?  Does the patch meet
> our coding standards?  Some of these boiler-plate tests should be
> automated and the patchwork data updated accordingly.

Yeah, eventually all of this needs to get automated.

Siddhesh

Re: [RFC] Archive old patches on patchwork?

[Joseph Myers]

On Thu, 19 Nov 2020, DJ Delorie via Libc-alpha wrote:

> Carlos and I had discussed this in the past... It's the kind of thing
> that can (should) be automated via some sort of bot - does the patch set
> apply cleanly to master?  Does master still build?  Does the patch meet
> our coding standards?  Some of these boiler-plate tests should be
> automated and the patchwork data updated accordingly.

For "Does the patch meet our coding standards?", if we allow general 
reformatting / other coding standards fixes for code that originated 
outside glibc but is now maintained in glibc and not updated from an 
upstream version (all the code that came from BSD sources or Sun fdlibm, 
for example), that may simplify such checks because we could have checks 
for particular features of the coding standards on the whole source tree 
(including running such checks as part of the testsuite), with as few 
exceptions as possible.

-- 
Joseph S. Myers
joseph@codesourcery.com