VEP Freeze on September 3rd - Inviting Exception Requests

[Vladik Romanovsky]

Hi everyone, 

According to our release schedule, tomorrow (September 3rd) is the VEP freeze date for this cycle. However, many VEPs have not converged yet and are still being worked on. 

We've encountered several limitations this development cycle, such as summer schedules and team members being out, which have impacted progress. 

If you're working on a VEP that needs more time, please reply to this thread or send an email to the list requesting a freeze exception. 

Please include a brief explanation of the status and why an extension is needed. 

Thank you!

[Daniel Sionov]

Hi
regarding https://github.com/kubevirt/enhancements/pull/87
I require at least one more day to make sure the comments are resolved properly

--
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/CAOTosKLjvkYTC6nLChUkLTKxePc_VR06wUFffB-OKRcRLUwjtw%40mail.gmail.com.

[Shelly Kagan]

Hello everyone,

I'm requesting a freeze exception for my VEP https://github.com/kubevirt/enhancements/pull/91.
I need more time to finalize the API design. This foundational work is critical for Incremental backup VEP (https://github.com/kubevirt/enhancements/issues/25).

We're currently in the final iteration of the API review, and a small extension is necessary to ensure the design is sound and ready for implementation.

Thank you for your consideration.

On Wed, Sep 3, 2025 at 3:32 PM 'Daniel Sionov' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hi
regarding https://github.com/kubevirt/enhancements/pull/87
I require at least one more day to make sure the comments are resolved properly

On Tue, Sep 2, 2025 at 6:38 PM 'Vladik Romanovsky' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hi everyone, 

According to our release schedule, tomorrow (September 3rd) is the VEP freeze date for this cycle. However, many VEPs have not converged yet and are still being worked on. 

We've encountered several limitations this development cycle, such as summer schedules and team members being out, which have impacted progress. 

If you're working on a VEP that needs more time, please reply to this thread or send an email to the list requesting a freeze exception. 

Please include a brief explanation of the status and why an extension is needed. 

Thank you!

--
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/CAOTosKLjvkYTC6nLChUkLTKxePc_VR06wUFffB-OKRcRLUwjtw%40mail.gmail.com.

--
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/CAHjckwdR-XLHeDRpV3-h3FSQe4VZ26unY2srLMDExqD0KrS7Zw%40mail.gmail.com.

--

Shelly Kagan

Senior Software Engineer

Red Hat

[Fan Zhang (SW-CLOUD)]

Hi 

I’d like to request a freeze exception for VEP #39 https://github.com/kubevirt/enhancements/issues/39 which I’ve recently taken over and am actively working on.

While there was an earlier proposal focused on GPU NUMA mapping, progress has stalled for several months. We now need to extend the scope to include GPUs, InfiniBand. The modified VEP will address mapping GPUs and InfiniBand devices to guest NUMA nodes in KubeVirt, which is critical for NCCL applications.

Additional time and effort will be required to move this forward effectively, so I am requesting an extension to continue the work.

Thank you for your consideration.

Best regards,

Fan Zhang

From: 'Vladik Romanovsky' via kubevirt-dev <kubevi...@googlegroups.com>
Date: Tuesday, September 2, 2025 at 8:38 AM
To: kubevirt-dev <kubevi...@googlegroups.com>
Subject: [kubevirt-dev] VEP Freeze on September 3rd - Inviting Exception Requests

External email: Use caution opening links or attachments

[Fabian Deutsch]

Heya,

forking this thread to highlight one part: We are piling up many VEPs on the 3 releases a year.

To provide a smoother process we mght want to explore ways how to land them less spiky.

Maybe we can double the amount of spikes where VEPs get attention, thus going from 3 to 6.

This is however independent of continuing to work on encouraging community members to step up and participate. .)

- fabian

---------- Forwarded message ---------
From: 'Vladik Romanovsky' via kubevirt-dev <kubevi...@googlegroups.com>
Date: Tue, Sep 2, 2025 at 5:38 PM
Subject: [kubevirt-dev] VEP Freeze on September 3rd - Inviting Exception Requests

To: kubevirt-dev <kubevi...@googlegroups.com>

--

[Vladik Romanovsky]

Thanks, Fabian.

Although a new thread with a new, distinct title would be better from my perspective.

One of the main ideas of the current VEP process is to concentrate the community efforts on prioritized tasks during the development cycle.

This begins with the design, when we should focus on reviewing the VEPs; implementation and review, when we should collaborate, review, and generally help get the PRs tied to the approved VEPs over the line; and finally, a stabilization phase.

One of the main obstacles right now, from my point of view, is that this process hasn't fully synced with the community's collective mind.
Some VEPs were open for a long period of time without any traction, and some were added very close to the VEP freeze.

You are suggesting doubling the number of design phases, but this will come at the cost of PR reviews.
Moreover, for larger features, it does take 8 to 10 weeks to develop, review, and merge.

From my point of view, creating another design phase for large features that don't align well with the release cycle will only create a distraction.

One thought I had was to create another review point for small (or even minor) VEPs whose review and implementation will not go beyond the declared code freeze.
But this is a half-baked idea.

That is only my personal view on the situation.
I hope others will express their opinions.

- Vladik

[Fabian Deutsch]

Vladik,

On Wed, Sep 3, 2025 at 10:41 PM Vladik Romanovsky <vrom...@redhat.com> wrote:

Thanks, Fabian.

Although a new thread with a new, distinct title would be better from my perspective.

Absolutely. I'll improve.

 

One of the main ideas of the current VEP process is to concentrate the community efforts on prioritized tasks during the development cycle.

This begins with the design, when we should focus on reviewing the VEPs; implementation and review, when we should collaborate, review, and generally help get the PRs tied to the approved VEPs over the line; and finally, a stabilization phase.

One of the main obstacles right now, from my point of view, is that this process hasn't fully synced with the community's collective mind.
Some VEPs were open for a long period of time without any traction, and some were added very close to the VEP freeze.

Thanks, that's a good point.

 

You are suggesting doubling the number of design phases, but this will come at the cost of PR reviews.
Moreover, for larger features, it does take 8 to 10 weeks to develop, review, and merge.

From my point of view, creating another design phase for large features that don't align well with the release cycle will only create a distraction.

One thought I had was to create another review point for small (or even minor) VEPs whose review and implementation will not go beyond the declared code freeze.

Also interesting, speak "low hanging fruit" PRs?

 

But this is a half-baked idea.

Mine as well ..

 

That is only my personal view on the situation.
I hope others will express their opinions.

+1

 fabian

 

- Vladik