Patchwork review workflow: archival rules

Patchwork review workflow: archival rules

[Siddhesh Poyarekar]

Hello,

What do people think about adding the following to the patch review 
workflow[1]?  This should help keep the queue under control.

~~~~~~
3. Maintaining your patch queue

3.1 (existing content)

3.2. Outdated Patches

To keep tha backlog in patchwork manageable, outdated patches may be 
archived at regular intervals.

  * Patches in Changes Requested status will be archived 1 year after 
they have been posted

  * Patches older than 3 months that fail to apply to the current main 
branch will be set to Rejected

  * Unresolved patches older than 2 years will be archived.
~~~~~~

Thanks,
Siddhesh

[1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

Re: Patchwork review workflow: archival rules

[Florian Weimer via Libc-alpha]

* Siddhesh Poyarekar:

>  * Patches older than 3 months that fail to apply to the current main
>    branch will be set to Rejected

Do we have tooling for that?

(I think detecting outdated submissions was a nice aspect of our Gerrit
trial.)

Thanks,
Florian

Re: Patchwork review workflow: archival rules

[Siddhesh Poyarekar]

On 11/16/21 11:16, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>>   * Patches older than 3 months that fail to apply to the current main
>>     branch will be set to Rejected
> 
> Do we have tooling for that?

Well for now I'm volunteering to be "the tool" ;)  I hope to find some 
time next month or during the 2.35 freeze to put in the auto-sync stuff 
I'm maintaining somewhere it can be triggered automatically, either as 
cron jobs on sourceware or git triggers.

> (I think detecting outdated submissions was a nice aspect of our Gerrit
> trial.)

Well I'd like to think that we're *building* a patch review system 
around patchwork :)

Siddhesh

Re: Patchwork review workflow: archival rules

[Paul Zimmermann]

       Dear Siddhesh,

this sounds good to me.

By the way, do we have an automatic mean to archive patches that are obsolete
because a new version has been posted?

Paul

> Date: Tue, 16 Nov 2021 09:52:58 +0530
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> 
> Hello,
> 
> What do people think about adding the following to the patch review 
> workflow[1]?  This should help keep the queue under control.
> 
> ~~~~~~
> 3. Maintaining your patch queue
> 
> 3.1 (existing content)
> 
> 3.2. Outdated Patches
> 
> To keep tha backlog in patchwork manageable, outdated patches may be 
> archived at regular intervals.
> 
>   * Patches in Changes Requested status will be archived 1 year after 
> they have been posted
> 
>   * Patches older than 3 months that fail to apply to the current main 
> branch will be set to Rejected
> 
>   * Unresolved patches older than 2 years will be archived.
> ~~~~~~
> 
> Thanks,
> Siddhesh
> 
> [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
> 

Re: Patchwork review workflow: archival rules

[Siddhesh Poyarekar]

On 11/16/21 14:24, Paul Zimmermann wrote:
>         Dear Siddhesh,
> 
> this sounds good to me.
> 
> By the way, do we have an automatic mean to archive patches that are obsolete
> because a new version has been posted?

Unfortunately not.  For now it is manual; we either mark our patches 
superseded ourselves or it languishes in the backlog.

Siddhesh

Re: Patchwork review workflow: archival rules

[Carlos O'Donell via Libc-alpha]

On 11/16/21 04:02, Siddhesh Poyarekar wrote:
> On 11/16/21 14:24, Paul Zimmermann wrote:
>>         Dear Siddhesh,
>>
>> this sounds good to me.
>>
>> By the way, do we have an automatic mean to archive patches that are obsolete
>> because a new version has been posted?
> 
> Unfortunately not.  For now it is manual; we either mark our patches superseded ourselves or it languishes in the backlog.

Kernel developers want this feature too.

"Change IDs for kernel patches" - 2019
https://lwn.net/Articles/797613/

The article discusses Gerrit's Change-Id which is a unique
Id used to track the patch through revisions. Linus doesn't
like this idea. There is traction to use message Ids for the
tracking via the "Link:" tag.

Then you have b4 which can find the latest version of a thing:
https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
- This seems to require you post v2, v3, vN, as a reply-to the original
  version.

I think "Link:" support in patchwork would really be the
best and developer tooling could improve to support it
automatically.

-- 
Cheers,
Carlos.

Re: Patchwork review workflow: archival rules

[Carlos O'Donell via Libc-alpha]

On 11/15/21 23:22, Siddhesh Poyarekar wrote:
> Hello,
> 
> What do people think about adding the following to the patch review
> workflow[1]?  This should help keep the queue under control.
> 
> ~~~~~~
> 3. Maintaining your patch queue
> 
> 3.1 (existing content)
> 
> 3.2. Outdated Patches
> 
> To keep tha backlog in patchwork manageable, outdated patches may be archived at regular intervals.
> 
>  * Patches in Changes Requested status will be archived 1 year after they have been posted


Agreed. And we can decrease the "1 year after" if we find it helps keep the queue cleaner.
 
>  * Patches older than 3 months that fail to apply to the current main branch will be set to Rejected

This will be an important step in keeping the queue clean.

I agree with this move.

>  * Unresolved patches older than 2 years will be archived.

Agreed.

> ~~~~~~
> 
> Thanks,
> Siddhesh
> 
> [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

All of this looks good to me.

We can change it any time we want IMO, so long as we set expectations and 
have a public discussion with our reason for making the change.

I'm curious if you have data about the above?

-- 
Cheers,
Carlos.

Re: Patchwork review workflow: archival rules

[Siddhesh Poyarekar]

On 11/30/21 03:50, Carlos O'Donell wrote:
> On 11/15/21 23:22, Siddhesh Poyarekar wrote:
>> Hello,
>>
>> What do people think about adding the following to the patch review
>> workflow[1]?  This should help keep the queue under control.
>>
>> ~~~~~~
>> 3. Maintaining your patch queue
>>
>> 3.1 (existing content)
>>
>> 3.2. Outdated Patches
>>
>> To keep tha backlog in patchwork manageable, outdated patches may be archived at regular intervals.
>>
>>   * Patches in Changes Requested status will be archived 1 year after they have been posted
> 
> 
> Agreed. And we can decrease the "1 year after" if we find it helps keep the queue cleaner.
>   
>>   * Patches older than 3 months that fail to apply to the current main branch will be set to Rejected
> 
> This will be an important step in keeping the queue clean.
> 
> I agree with this move.
> 
>>   * Unresolved patches older than 2 years will be archived.
> 
> Agreed.
> 
>> ~~~~~~
>>
>> Thanks,
>> Siddhesh
>>
>> [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
> 
> All of this looks good to me.
> 
> We can change it any time we want IMO, so long as we set expectations and
> have a public discussion with our reason for making the change.

Thanks, I'll make the change in the wiki and run some commands over the 
weekend to implement this.

> I'm curious if you have data about the above?

What kind of data are you looking for?  I came up with arbitrary time 
limits that I believe are conservative enough.  Rebasing a patchset that 
doesn't apply to current mainline for example is a necessary condition 
and there's no way we'd accept it unless it is rebased (and hence a new 
version posted) but I still proposed waiting 3 months before changing 
status as a conservative measure.

Similarly for archiving Changes Requested patches; there's no way it's 
going to come back to New or Accepted/Committed unless the consensus on 
the exact same patch changes, which I have never seen happen in the past 
decade.  That is, there's always an updated version that drives 
consensus.  I still kept the timeout at 1 year as a conservative start.

Siddhesh

Re: Patchwork review workflow: archival rules

[Siddhesh Poyarekar]

On 30/11/2021 05:47, Siddhesh Poyarekar wrote:
> On 11/30/21 03:50, Carlos O'Donell wrote:
>> On 11/15/21 23:22, Siddhesh Poyarekar wrote:
>>> Hello,
>>>
>>> What do people think about adding the following to the patch review
>>> workflow[1]?  This should help keep the queue under control.
>>>
>>> ~~~~~~
>>> 3. Maintaining your patch queue
>>>
>>> 3.1 (existing content)
>>>
>>> 3.2. Outdated Patches
>>>
>>> To keep tha backlog in patchwork manageable, outdated patches may be 
>>> archived at regular intervals.
>>>
>>>   * Patches in Changes Requested status will be archived 1 year after 
>>> they have been posted
>>
>>
>> Agreed. And we can decrease the "1 year after" if we find it helps 
>> keep the queue cleaner.
>>>   * Patches older than 3 months that fail to apply to the current 
>>> main branch will be set to Rejected
>>
>> This will be an important step in keeping the queue clean.
>>
>> I agree with this move.
>>
>>>   * Unresolved patches older than 2 years will be archived.
>>
>> Agreed.
>>
>>> ~~~~~~
>>>
>>> Thanks,
>>> Siddhesh
>>>
>>> [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
>>
>> All of this looks good to me.
>>
>> We can change it any time we want IMO, so long as we set expectations and
>> have a public discussion with our reason for making the change.
> 
> Thanks, I'll make the change in the wiki and run some commands over the 
> weekend to implement this.

Sorry I forgot about this; I've updated the wiki now and will run 
updates soon.

Siddhesh