VEP #233: Reworked to use dedicated release branch maintainer groups

[Lee Yarwood]

Hi all,

After several downstream discussions about the impact of VEP #233, we'd like
to suggest a rework of the proposal. The original hard EOL cutoff would push
release branch maintenance into downstream-only or midstream forks, adding
significant CI and tooling overhead for vendors who still need those branches.
Instead, we're proposing a governance model that keeps everything upstream
while addressing the core reviewer burden.

I've posted [PR #341][1] with the reworked VEP. This supersedes the previous
alternative PRs ([#334][2], [#335][3], [#317][4]), which have been closed.

## What changed

The original VEP proposed a hard 3-release EOL cutoff to bound the number of
active branches. Community feedback identified that the root problem isn't the
number of branches — it's that the same core maintainers who develop features
on `main` also review every backport across all release branches. Archiving
old branches doesn't address this, since the most recent branches are the
busiest for backports.

The reworked VEP replaces the fixed cutoff with two changes:

**Dedicated release branch maintainer groups**: All release branches are
owned by dedicated maintainer groups from the point they are cut. Core `main`
branch maintainers focus on feature development; the release branch groups
handle backport review and CI health. These groups operate under the oversight
of the project's core approvers, who define backporting policy, mentor members,
and provide technical guidance on complex backports.

This also creates a contributor onboarding path — reviewing backports builds
codebase familiarity and review experience under the mentorship of core
maintainers, making release branch maintainers natural candidates for future
SIG approver status on `main`.

**Maintainer-driven EOL**: Instead of a hard release count, branches
transition to EOL when no dedicated maintainer opts in to keep them alive. An
EOL proposal PR is opened and must remain open for at least one month. Anyone
can object by committing to continue maintenance. If no one objects, the
branch is archived. This is modeled on [OpenStack's stable branch policy][5],
which has operated at this scale for over a decade.

## What's next

The PR is open for review. The exact team structure and review requirements
for the release branch maintainer groups are left as implementation details to
be determined during the graduation process — the VEP focuses on establishing
the governance model.

Feedback welcome on the PR or this thread.

Thanks,
Lee

[1]: https://github.com/kubevirt/enhancements/pull/341
[2]: https://github.com/kubevirt/enhancements/pull/334
[3]: https://github.com/kubevirt/enhancements/pull/335
[4]: https://github.com/kubevirt/enhancements/pull/317
[5]: https://docs.openstack.org/project-team-guide/stable-branches.html

[Felix Matouschek]

Am Mittwoch, dem 17.06.2026 um 18:25 +0100 schrieb 'Lee Yarwood' via
kubevirt-dev:

I'm skeptical that putting more load (or keeping it the same) onto the
shoulders of the core approvers will help with anything. Wasn't the
idea of this initiative to lessen the maintenance burden on core
approvers in the first place?

[Lee Yarwood]

On Thu, 18 Jun 2026 at 10:47, Felix Matouschek <fmat...@redhat.com> wrote:
> > The reworked VEP replaces the fixed cutoff with two changes:
> >
> > **Dedicated release branch maintainer groups**: All release branches
> > are
> > owned by dedicated maintainer groups from the point they are cut.
> > Core `main`
> > branch maintainers focus on feature development; the release branch
> > groups
> > handle backport review and CI health. These groups operate under the
> > oversight
> > of the project's core approvers, who define backporting policy,
> > mentor members,
>
> I'm skeptical that putting more load (or keeping it the same) onto the
> shoulders of the core approvers will help with anything. Wasn't the
> idea of this initiative to lessen the maintenance burden on core
> approvers in the first place?

Yeah I appreciate that this doesn't immediately remove the burden from
the core and SIG approval groups but we have to start somewhere.
Initially the release branch approval group will need to consist of a
subset of the core and SIG approval groups. Over time, this should
hopefully change as interested individuals are vouched for, onboarded
and promoted to the release branch approval group.

Cheers,

Lee