discussuion: should we shorten PR and issue lifecycle spans?

Daniel Hiller

unread,

Mar 16, 2026, 8:18:57 AMMar 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.

For k/kubevirt currently there's 26 rotten [2] and 14 stale [3] present - notably in case of lane changes all those consume CI resources as in that case the lanes are re-triggered.

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?

[1]: https://github.com/kubevirt/project-infra/blob/fb0392a4d7bf80b5ad4e634339027bd740156087/github/ci/prow-deploy/files/jobs/kubevirt/project-infra/project-infra-periodics.yaml#L118

[2]: https://github.com/search?q=repo%3Akubevirt%2Fkubevirt+base%3Amain+label%3Alifecycle%2Frotten+is%3Aopen+is%3Apr&type=pullrequests

[3]: https://github.com/search?q=repo%3Akubevirt%2Fkubevirt+base%3Amain+label%3Alifecycle%2Fstale+is%3Aopen+is%3Apr&type=pullrequests

[4]: https://github.com/search?q=repo%3Akubevirt%2Fkubevirt+base%3Amain+-label%3Alifecycle%2Fstale+-label%3Alifecycle%2Frotten+is%3Aopen+is%3Apr&type=pullrequests&s=updated&o=asc

[5]: https://github.com/kubernetes/test-infra/blob/a6b84c7961b3c9e57db64a3015540460efddca30/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-contribex-k8s-triage-robot.yaml#L211

--

Kind regards,

Daniel Hiller

He / Him / His

Principal Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com

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

unread,

Mar 16, 2026, 9:37:56 AMMar 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.

For k/kubevirt currently there's 26 rotten [2] and 14 stale [3] present - notably in case of lane changes all those consume CI resources as in that case the lanes are re-triggered.

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?

[1]: https://github.com/kubevirt/project-infra/blob/fb0392a4d7bf80b5ad4e634339027bd740156087/github/ci/prow-deploy/files/jobs/kubevirt/project-infra/project-infra-periodics.yaml#L118
[2]: https://github.com/search?q=repo%3Akubevirt%2Fkubevirt+base%3Amain+label%3Alifecycle%2Frotten+is%3Aopen+is%3Apr&type=pullrequests
[3]: https://github.com/search?q=repo%3Akubevirt%2Fkubevirt+base%3Amain+label%3Alifecycle%2Fstale+is%3Aopen+is%3Apr&type=pullrequests
[4]: https://github.com/search?q=repo%3Akubevirt%2Fkubevirt+base%3Amain+-label%3Alifecycle%2Fstale+-label%3Alifecycle%2Frotten+is%3Aopen+is%3Apr&type=pullrequests&s=updated&o=asc
[5]: https://github.com/kubernetes/test-infra/blob/a6b84c7961b3c9e57db64a3015540460efddca30/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-contribex-k8s-triage-robot.yaml#L211

--
Kind regards,

Daniel Hiller
He / Him / His
Principal Software Engineer, KubeVirt CI, OpenShift Virtualization
Red Hat
dhi...@redhat.com
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  

--
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

unread,

Mar 16, 2026, 10:26:36 AMMar 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.

For k/kubevirt currently there's 26 rotten [2] and 14 stale [3] present - notably in case of lane changes all those consume CI resources as in that case the lanes are re-triggered.

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.

[1]: https://kubevirt.devstats.cncf.io/d/10/pr-time-to-engagement?orgId=1&var-period=d7&var-repogroup_name=All&from=now-1y&to=now-1w

--

Best,

Daniel

Orel Misan

unread,

Mar 17, 2026, 5:27:29 AMMar 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

unread,

Mar 17, 2026, 5:36:43 AMMar 17

to Orel Misan, Daniel Hiller, Luboslav Pivarc, kubevirt-dev

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.

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

unread,

Mar 17, 2026, 8:09:00 AMMar 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

unread,

Mar 17, 2026, 8:18:58 AMMar 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.

To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CALpNySyzMoXRCO-WWGbWqQ65xe0XdgbF3vCf7%2BwkCyrBYhKrZQ%40mail.gmail.com.

Daniel Hiller

unread,

Mar 18, 2026, 12:05:26 PMMar 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

unread,

Mar 19, 2026, 12:48:47 PMMar 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.

My questions:
- 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

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

unread,

Mar 20, 2026, 5:59:52 AMMar 20

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.

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.

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.

[1]: https://github.com/kubernetes-sigs/prow/blob/25576911ab27d49eab4879c3db0cae010c3d83cf/pkg/plugins/config.go#L482

[2]: https://github.com/kubernetes-sigs/prow/blob/25576911ab27d49eab4879c3db0cae010c3d83cf/pkg/config/tide.go#L509

- 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

Daniel Hiller

unread,

Apr 15, 2026, 8:49:22 AMApr 15

to Andrew Burden, Lee Yarwood, Orel Misan, Luboslav Pivarc, kubevirt-dev

Hey all,

Going back to what we discussed, here's my proposal:

* we set stale/rotten/close cycle times for pull requests from 90/30/30 to 45/14/7

* issue cycle time stays as is

This would shorten the overall cycle time from 150 to 90 days that a PR is being closed after, while still giving more than a month for the first reaction (note: any change on a PR will again reset the cycle to the beginning)

Also it would allow two weeks for reaction if a PR gets stale, and if then there's still no reaction it is closed after another week.

WDYT?

--

Best,

Daniel

Orel Misan

unread,

Apr 15, 2026, 9:14:11 AMApr 15

to Daniel Hiller, Andrew Burden, Lee Yarwood, Luboslav Pivarc, kubevirt-dev

Hi Daniel,

Thank you for following up on this!

How about a 31/7/7 cycle for pull requests? This would set the overall lifespan to 45 days, allowing us to be even more proactive in managing the PR queue and CI resources.
Contributors would still have the option to freeze or reopen PRs as needed.

Best regards,

Orel

Daniel Hiller

unread,

Apr 16, 2026, 3:51:37 AM (14 days ago) Apr 16

to Orel Misan, Andrew Burden, Lee Yarwood, Luboslav Pivarc, kubevirt-dev

Hey all, Orel,

(note the correction inline)

On Wed, Apr 15, 2026 at 3:14 PM Orel Misan <omi...@redhat.com> wrote:

Hi Daniel,

Thank you for following up on this!

How about a 31/7/7 cycle for pull requests? This would set the overall lifespan to 45 days, allowing us to be even more proactive in managing the PR queue and CI resources.
Contributors would still have the option to freeze or reopen PRs as needed.

I believe that Andrew was concerned about the 31 days not being enough for a reviewer to look at the PR (holidays or whatever) even though those are obliged to review in a reasonable time frame [1] . As the blunderbuss plugin assigns those reviewers directly when the PR is created (except if it was created as draft, which is reasonable) it's on them to react and not let the PR go stale. Besides that I think it's a reasonable measure to increase engagement for contributors even with this "longer" timespan.

Note that we are already reducing by 84 days with this proposal.

[1] https://github.com/kubevirt/community/blob/main/membership_policy.md#reviewer

I stand corrected: 66 days it is :-/

--

Best,

Daniel

Luboslav Pivarc

unread,

Apr 16, 2026, 11:46:53 AM (13 days ago) Apr 16

to Daniel Hiller, Orel Misan, Andrew Burden, Lee Yarwood, kubevirt-dev

+1 on 45/14/7, @Daniel Hiller have you run this through repo to see how much would it impact opened PRs?

-Lubo

Orel Misan

unread,

Apr 16, 2026, 1:28:03 PM (13 days ago) Apr 16

to Luboslav Pivarc, Daniel Hiller, Andrew Burden, Lee Yarwood, kubevirt-dev

Hi,

Approximately 19% of the open PRs (68 out of 363) have not been updated for 45 days or more.

I used the following query to pull this data:

`curl -s "https://api.github.com/search/issues?q=repo:kubevirt/kubevirt+type:pr+state:open+updated:<2026-03-02" | jq '.total_count'`

Orel

Daniel Hiller

unread,

Apr 20, 2026, 6:26:47 AM (9 days ago) Apr 20

to Orel Misan, Luboslav Pivarc, Andrew Burden, Lee Yarwood, kubevirt-dev

Hey all

On Thu, Apr 16, 2026 at 7:28 PM Orel Misan <omi...@redhat.com> wrote:

Hi,

Approximately 19% of the open PRs (68 out of 363) have not been updated for 45 days or more.

I used the following query to pull this data:
`curl -s "https://api.github.com/search/issues?q=repo:kubevirt/kubevirt+type:pr+state:open+updated:<2026-03-02" | jq '.total_count'`

As of today the numbers are:

# soon to get stale PRs

❯ curl -s "https://api.github.com/search/issues?q=repo:kubevirt/kubevirt+type:pr+state:open+updated:<2026-03-02" | jq '.total_count'

63

# soon to get rotten PRs

❯ curl -s "https://api.github.com/search/issues?q=repo:kubevirt/kubevirt+type:pr+state:open+label:lifecycle/stale+updated:<2026-04-06" | jq '.total_count'
6

# soon to get closed PRs

❯ curl -s "https://api.github.com/search/issues?q=repo:kubevirt/kubevirt+type:pr+state:open+label:lifecycle/rotten+updated:<2026-04-13" | jq '.total_count'
9

--

Best,

Daniel

Daniel Hiller

unread,

Apr 20, 2026, 6:27:21 AM (9 days ago) Apr 20

to Orel Misan, Luboslav Pivarc, Andrew Burden, Lee Yarwood, kubevirt-dev

Hey,

so I'll move forward and create a PR, will get back when I have it ready.

--

Best,

Daniel

Daniel Hiller

unread,

Apr 21, 2026, 12:42:29 PM (8 days ago) Apr 21

to Orel Misan, Luboslav Pivarc, Andrew Burden, Lee Yarwood, kubevirt-dev

Hey all,

here's the PR: https://github.com/kubevirt/project-infra/pull/4989/changes

Comments welcome!

--

Best,

Daniel

Reply all

Reply to author

Forward