discussuion: should we shorten PR and issue lifecycle spans?
17 views
Skip to first unread message
Daniel Hiller
Mar 16, 2026, 8:18:57 AM (4 days ago) Mar 16
to kubevirt-dev, Orel Misan
Hey all,
this morning in sig-ci meeting it was mentioned that there's PRs present dating from last year with no update since then.
Thus I'd like to raise a discussion around the GitHub PR and Issue lifespan.
Current situation for PRs and Issues in the KubeVirt org [1]:
* after 90 days with no updates PRs and issues are labeled as `lifecycle/stale`,
* after further 30 days with no updates those are labeled as `lifecycle/rotten`,
* after further 30 days with no updates those are closed.
This effectively means 150 days after which a PR is closed if there's no action performed.
Of the open PRs against k/kubevirt the one with the least recent change is from Dec 18th 25 [4]
So the question is whether we should shorten the intervals towards stale, rotten, and/or close?
My take on this is that a gentle reminder after 30 days by labelling the PR as stale would be a good start. Which would mean changing the initial 90 days to 30 and the overall lifespan to 90 days.
A more eager change would be additionally changing the stale -> rotten period to 14 days and then closing rotten after seven days.
OTOH I think we should be welcoming all contributions and it is sad that those are getting stale at all. So perhaps we need to also rephrase the comments being placed [1] in some way to make people less turned off by this change.
Another reason to stick to the current state: Kubernetes is doing the same lifespan changes (90/30/30) as we do [5]
WDYT?
Kind regards,
Daniel Hiller
He / Him / His
Principal Software Engineer, KubeVirt CI, OpenShift Virtualization
 |
Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty
Luboslav Pivarc
Mar 16, 2026, 9:37:56 AM (4 days ago) Mar 16
to Daniel Hiller, kubevirt-dev, Orel Misan
Hi Daniel,
On Mon, Mar 16, 2026 at 1:19 PM 'Daniel Hiller' via kubevirt-dev <kubevi...@googlegroups.com> wrote:
Hey all,this morning in sig-ci meeting it was mentioned that there's PRs present dating from last year with no update since then.Thus I'd like to raise a discussion around the GitHub PR and Issue lifespan.Current situation for PRs and Issues in the KubeVirt org [1]:* after 90 days with no updates PRs and issues are labeled as `lifecycle/stale`,* after further 30 days with no updates those are labeled as `lifecycle/rotten`,* after further 30 days with no updates those are closed.This effectively means 150 days after which a PR is closed if there's no action performed.
In my personal opinion, this seems like a lot of time and if nobody really engaged for almost half a year, there's a low chance of them doing so now.
Of the open PRs against k/kubevirt the one with the least recent change is from Dec 18th 25 [4]So the question is whether we should shorten the intervals towards stale, rotten, and/or close?My take on this is that a gentle reminder after 30 days by labelling the PR as stale would be a good start. Which would mean changing the initial 90 days to 30 and the overall lifespan to 90 days.
I would just ask if we know what is the P50/90 for "time to get review." The "time to get review" should be the leading metric upon which we base the stale state imho.
-Lubo
A more eager change would be additionally changing the stale -> rotten period to 14 days and then closing rotten after seven days.OTOH I think we should be welcoming all contributions and it is sad that those are getting stale at all. So perhaps we need to also rephrase the comments being placed [1] in some way to make people less turned off by this change.Another reason to stick to the current state: Kubernetes is doing the same lifespan changes (90/30/30) as we do [5]WDYT?--Kind regards,
Daniel Hiller
He / Him / His
Principal Software Engineer, KubeVirt CI, OpenShift Virtualization
--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAK%2BeyL44Liedh%3DYm958xRTnjza6vCSCKDhGiFyAMn4koSHM7xQ%40mail.gmail.com.
Daniel Hiller
Mar 16, 2026, 10:26:36 AM (4 days ago) Mar 16
to Luboslav Pivarc, kubevirt-dev, Orel Misan
On Mon, Mar 16, 2026 at 2:37 PM Luboslav Pivarc <lpi...@redhat.com> wrote:
Hi Daniel,On Mon, Mar 16, 2026 at 1:19 PM 'Daniel Hiller' via kubevirt-dev <kubevi...@googlegroups.com> wrote:Hey all,this morning in sig-ci meeting it was mentioned that there's PRs present dating from last year with no update since then.Thus I'd like to raise a discussion around the GitHub PR and Issue lifespan.Current situation for PRs and Issues in the KubeVirt org [1]:* after 90 days with no updates PRs and issues are labeled as `lifecycle/stale`,* after further 30 days with no updates those are labeled as `lifecycle/rotten`,* after further 30 days with no updates those are closed.This effectively means 150 days after which a PR is closed if there's no action performed.In my personal opinion, this seems like a lot of time and if nobody really engaged for almost half a year, there's a low chance of them doing so now.
Of the open PRs against k/kubevirt the one with the least recent change is from Dec 18th 25 [4]So the question is whether we should shorten the intervals towards stale, rotten, and/or close?My take on this is that a gentle reminder after 30 days by labelling the PR as stale would be a good start. Which would mean changing the initial 90 days to 30 and the overall lifespan to 90 days.I would just ask if we know what is the P50/90 for "time to get review." The "time to get review" should be the leading metric upon which we base the stale state imho.
According to the "PR to engagement" dashboard if I read the data right the max of P85 is roughly 5 weeks [1] - I can only guess that this is caused by holiday season.
--
Best,
Daniel
Orel Misan
Mar 17, 2026, 5:27:29 AM (3 days ago) Mar 17
to Daniel Hiller, Luboslav Pivarc, kubevirt-dev
Hi Daniel,
Thank you for raising this subject!
I propose closing inactive PRs after 45 days. I believe this is a good compromise that accounts for inactivity due to holidays or context switching, while still maintaining a reasonable number of open PRs for our CI to handle.
Orel
Lee Yarwood
Mar 17, 2026, 5:36:43 AM (3 days ago) Mar 17
to Orel Misan, Daniel Hiller, Luboslav Pivarc, kubevirt-dev
Thanks Daniel!
Is there a distinction for draft PRs that don't consume CI resources and can easily be filtered out by folks looking for PRs to review? I heavily use draft PRs to capture ideas and early PoCs. I'd hate to see these auto-closed as part of this.
Cheers,
Lee
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CALzEmMd-0Jz0%3Dj2Qu0jV22_8gO2A3uccdzcc_54mWvkNv17%3DPw%40mail.gmail.com.
Itamar Holder
Mar 17, 2026, 8:09:00 AM (3 days ago) Mar 17
to Lee Yarwood, Orel Misan, Daniel Hiller, Luboslav Pivarc, kubevirt-dev
Hey there!
Thank you Daniel! I absolutely support this direction!
150 days seems way too long in my opinion.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAPkJ9DvjLq1fBANFL1pEEJM6ozZNjqEJW5wkFp%3DwLNv2Jbg7SQ%40mail.gmail.com.
Daniel Sionov
Mar 17, 2026, 8:18:58 AM (3 days ago) Mar 17
to Itamar Holder, Lee Yarwood, Orel Misan, Daniel Hiller, Luboslav Pivarc, kubevirt-dev
Hi
I agree with 45 days, PR authors can manually stop PRs from rotting to avoid closing them.
I agree with 45 days, PR authors can manually stop PRs from rotting to avoid closing them.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CALpNySyzMoXRCO-WWGbWqQ65xe0XdgbF3vCf7%2BwkCyrBYhKrZQ%40mail.gmail.com.
Daniel Hiller
Mar 18, 2026, 12:05:26 PM (2 days ago) Mar 18
to Lee Yarwood, Orel Misan, Luboslav Pivarc, kubevirt-dev
Hey Lee,
On Tue, Mar 17, 2026 at 10:36 AM Lee Yarwood <lyar...@redhat.com> wrote:
Thanks Daniel!I agree with Orel's proposal of 45 days for active PRs, this seems reasonable to me.Is there a distinction for draft PRs that don't consume CI resources and can easily be filtered out by folks looking for PRs to review? I heavily use draft PRs to capture ideas and early PoCs. I'd hate to see these auto-closed as part of this.
Not that I am currently aware of, but it should be easy to add that to the github query - good point.
--
Best,
Daniel
Andrew Burden
Mar 19, 2026, 12:48:47 PM (yesterday) Mar 19
to Daniel Hiller, Lee Yarwood, Orel Misan, Luboslav Pivarc, kubevirt-dev
Thanks for raising this Daniel,
From my POV, changing the total time frame from 150 days to 45 days to close an issue/pr seems really drastic. I get that 90 days for something to go stale seems incredibly generous, and it is for those of us who are working with these repos every day, but for folks who only contribute sparingly, it doesn't take much for the time between contributions to balloon out.
I would just ask if we know what is the P50/90 for "time to get review." The "time to get review" should be the leading metric upon which we base the stale state imho.
Judging from devstats [1] over a 12 month period across the org, it seems the average of ~1.5 weeks to engagement, with a P85 of ~4 weeks to engagement. I don't believe we have stats on 'time to get review' so that might be the best we have to work with.
Looking at Daniel's linked queries for stale and rotten labelled PRs (and also looking at issues in k/kubevirt since the same mechanism applies to them), it seems that:
~30% of the PRs (8/25 rotten and 4/13 stale), and
~50% of the issues (6/13 rotten and 17/34 stale)
are from non-core contributors. I've only had a superficial look over a sample of these but a bunch of those have gone stale because they're waiting on a response from the community. It'd be a shame to make it harder for new folks to contribute.
OTOH I think we should be welcoming all contributions and it is sad that those are getting stale at all. So perhaps we need to also rephrase the comments being placed [1] in some way to make people less turned off by this change.
100% in agreement. And I say that fully acknowledging that I am part of the problem: I have a terrible track record with keeping on top of this in the past 6 months (I'm trying to do better).
Whatever we decide, I think an update to the comment text would be beneficial. I will raise an issue.
Whatever we decide, I think an update to the comment text would be beneficial. I will raise an issue.
My questions:
- Is it possible to prevent PRs with a 'stale' or 'rotten' label from consuming CI resources?
- Is it possible to prevent PRs with a 'stale' or 'rotten' label from consuming CI resources?
- Is CI resource use the only concern or are there additional noise issues with these labels?
- Since this impacts issues as well, are we able to set different timelines to bugs than to PRs?
- Instead of shortening the stale timeframe, is there another way of getting attention on them?
- If 2/3 of stale and rotten PRs are from core community members, should these be closed or moved to a state where they don't consume CI?
PR authors can manually stop PRs from rotting to avoid closing them.
TBH I didn't realise this was something non-members could do. We should add this to the comment text.
Thank you,
Andrew
[1] https://kubevirt.devstats.cncf.io/d/10/pr-time-to-engagement?orgId=1&var-period=d7&var-repogroup_name=All
Thank you,
Andrew
[1] https://kubevirt.devstats.cncf.io/d/10/pr-time-to-engagement?orgId=1&var-period=d7&var-repogroup_name=All
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAK%2BeyL6JwUM-a%3DdwOi_vSFFiC-T72z%3DcS32b7vfT-GL_EM_72A%40mail.gmail.com.
Daniel Hiller
5:59 AM (10 hours ago) 5:59 AM
to Andrew Burden, Lee Yarwood, Orel Misan, Luboslav Pivarc, kubevirt-dev
On Thu, Mar 19, 2026 at 5:48 PM Andrew Burden <abu...@redhat.com> wrote:
Thanks for raising this Daniel,From my POV, changing the total time frame from 150 days to 45 days to close an issue/pr seems really drastic. I get that 90 days for something to go stale seems incredibly generous, and it is for those of us who are working with these repos every day, but for folks who only contribute sparingly, it doesn't take much for the time between contributions to balloon out.Judging from devstats [1] over a 12 month period across the org, it seems the average of ~1.5 weeks to engagement, with a P85 of ~4 weeks to engagement. I don't believe we have stats on 'time to get review' so that might be the best we have to work with.I would just ask if we know what is the P50/90 for "time to get review." The "time to get review" should be the leading metric upon which we base the stale state imho.Looking at Daniel's linked queries for stale and rotten labelled PRs (and also looking at issues in k/kubevirt since the same mechanism applies to them), it seems that:~30% of the PRs (8/25 rotten and 4/13 stale), and~50% of the issues (6/13 rotten and 17/34 stale)are from non-core contributors. I've only had a superficial look over a sample of these but a bunch of those have gone stale because they're waiting on a response from the community. It'd be a shame to make it harder for new folks to contribute.OTOH I think we should be welcoming all contributions and it is sad that those are getting stale at all. So perhaps we need to also rephrase the comments being placed [1] in some way to make people less turned off by this change.100% in agreement. And I say that fully acknowledging that I am part of the problem: I have a terrible track record with keeping on top of this in the past 6 months (I'm trying to do better).
Whatever we decide, I think an update to the comment text would be beneficial. I will raise an issue.My questions:
- Is it possible to prevent PRs with a 'stale' or 'rotten' label from consuming CI resources?
Not that I am aware of, trigger config [1] doesn't have MissingLabels as TideQuery has [2] .
We could think about moving stale PRs back to draft though.
- Is CI resource use the only concern or are there additional noise issues with these labels?
To me also reviewer burden might be a concern.
- Since this impacts issues as well, are we able to set different timelines to bugs than to PRs?
Yes, we can split the queries into issues and pull requests.
- Instead of shortening the stale timeframe, is there another way of getting attention on them?
In earlier days we had the habit of triaging PRs (during community meetings), not sure whether that has been dropped in a way?
- If 2/3 of stale and rotten PRs are from core community members, should these be closed or moved to a state where they don't consume CI?
converted back to draft imho - but I think that's what people are doing already?
--
Best,
Daniel
Reply all
Reply to author
Forward
0 new messages