* Patchwork review workflow: archival rules
@ 2021-11-16 4:22 Siddhesh Poyarekar
2021-11-16 5:46 ` Florian Weimer
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-16 4:22 UTC (permalink / raw)
To: libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-16 4:22 Patchwork review workflow: archival rules Siddhesh Poyarekar
@ 2021-11-16 5:46 ` Florian Weimer
2021-11-16 5:53 ` Siddhesh Poyarekar
2021-11-16 8:54 ` Paul Zimmermann
2021-11-29 22:20 ` Carlos O'Donell
2 siblings, 1 reply; 9+ messages in thread
From: Florian Weimer @ 2021-11-16 5:46 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-16 5:46 ` Florian Weimer
@ 2021-11-16 5:53 ` Siddhesh Poyarekar
0 siblings, 0 replies; 9+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-16 5:53 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-16 4:22 Patchwork review workflow: archival rules Siddhesh Poyarekar
2021-11-16 5:46 ` Florian Weimer
@ 2021-11-16 8:54 ` Paul Zimmermann
2021-11-16 9:02 ` Siddhesh Poyarekar
2021-11-29 22:20 ` Carlos O'Donell
2 siblings, 1 reply; 9+ messages in thread
From: Paul Zimmermann @ 2021-11-16 8:54 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: libc-alpha
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-16 8:54 ` Paul Zimmermann
@ 2021-11-16 9:02 ` Siddhesh Poyarekar
2021-11-29 22:19 ` Carlos O'Donell
0 siblings, 1 reply; 9+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-16 9:02 UTC (permalink / raw)
To: Paul Zimmermann; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-16 9:02 ` Siddhesh Poyarekar
@ 2021-11-29 22:19 ` Carlos O'Donell
0 siblings, 0 replies; 9+ messages in thread
From: Carlos O'Donell @ 2021-11-29 22:19 UTC (permalink / raw)
To: Siddhesh Poyarekar, Paul Zimmermann; +Cc: 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-16 4:22 Patchwork review workflow: archival rules Siddhesh Poyarekar
2021-11-16 5:46 ` Florian Weimer
2021-11-16 8:54 ` Paul Zimmermann
@ 2021-11-29 22:20 ` Carlos O'Donell
2021-11-30 0:17 ` Siddhesh Poyarekar
2 siblings, 1 reply; 9+ messages in thread
From: Carlos O'Donell @ 2021-11-29 22:20 UTC (permalink / raw)
To: Siddhesh Poyarekar, 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-29 22:20 ` Carlos O'Donell
@ 2021-11-30 0:17 ` Siddhesh Poyarekar
2022-02-07 14:09 ` Siddhesh Poyarekar
0 siblings, 1 reply; 9+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-30 0:17 UTC (permalink / raw)
To: Carlos O'Donell, libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patchwork review workflow: archival rules
2021-11-30 0:17 ` Siddhesh Poyarekar
@ 2022-02-07 14:09 ` Siddhesh Poyarekar
0 siblings, 0 replies; 9+ messages in thread
From: Siddhesh Poyarekar @ 2022-02-07 14:09 UTC (permalink / raw)
To: Carlos O'Donell, libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-02-07 14:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-16 4:22 Patchwork review workflow: archival rules Siddhesh Poyarekar
2021-11-16 5:46 ` Florian Weimer
2021-11-16 5:53 ` Siddhesh Poyarekar
2021-11-16 8:54 ` Paul Zimmermann
2021-11-16 9:02 ` Siddhesh Poyarekar
2021-11-29 22:19 ` Carlos O'Donell
2021-11-29 22:20 ` Carlos O'Donell
2021-11-30 0:17 ` Siddhesh Poyarekar
2022-02-07 14:09 ` Siddhesh Poyarekar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).