Xen Summit 2025 - "feature tracking for releases" design session notes

[Alex Brett <alex.brett@xxxxxxxxxx>]

(Apologies in advance for any misquotes etc)

Jan Beulich (JB):
Intention is not to talk about 4.21 (largely done feature wise), plan is to 
think about a more structured way of deciding e.g. at beginning of a release 
cycle what features we'd like to have in the release.

What we have been doing is a large set of work with no plan, not taking into 
account importance / ordering etc.

Andrew Cooper (AC): Everything we do is reactive, patches come along and may go 
in may not.

JB: Patches indicate someone is interested in functionality, but in some 
situations may go in quickly, others may not or be abandoned by author etc. 
Having an overview of what people want in a release and are committed to 
working on (both author and reviewers etc) (AC: and necessary testing) would be 
good.

Is it something people think could work, if at beginning of release cycle we 
settled on a plan of what we want in the release. New things can of course 
appear, but we'd be in a slightly better position of knowing what a release can 
bring?

Rich Persaud (RP): Is there still a single release manager for each release? 
(room: Yes)
JB: Don't want to move away from that model

AC: Tried to do this for the previous few releases, e.g. on the community call 
presented "here's what XenServer is thinking of doing in the next release".
JB: Only the first step, then need to keep track of progress on things we 
intend to be in the release.

RP: How do you transfer knowledge from old to new release manager?

JB: New manager turns to old one with questions.
Oleksii Kurochko (OK): This time had short meeting where previous manager 
(Henry) told what he thought was necessary to know.

Daniel Smith (DS): Useful for people to know which items to focus on that are 
likely to make a release over e.g. review work on things which are not.

AC: Complexity of review grows as series get larger. FRED example - went in 
with 5 different series (some of which didn't say FRED). Splitting things up 
makes things easier to review and can end up with some parts getting in to some 
releases (even with no overall feature to talk about in that release).

AC: Wherever possible we should be helping people to get parts of series in to 
simplify remaining parts.

Discussion around whether this would affect decisions as to what goes in. What 
about when authors have multiple things they're working on - clarification 
around multiple things from same author or different authors (subtlety as e.g. 
XenServer may have 3 things from different authors but same managers etc).

Roger Pau Monne (RPM): Can't force people as to what they should review
JB: No, but if we had defined features for the release it would help reviewers 
make their own decisions knowing what is more important
AC: Tricky in some cases, e.g. XenServer and secure boot - we said it was the 
most important thing for us, but then nothing happened for ages. Importance 
therefore decreased as it became clear other problems meant it wouldn't make 
it. Need to have a way of knowing when things change in priority

JB: Can't commit other people in an open source community

Marek Marczykowski-Górecki (MM): Community update emails from release manager 
have been very useful. Don't see why these couldn't include plans about things 
that are not yet posted to the list.
RPM: Mails could get crowded if it lists anything people just have an intention 
to do rather than actual patches.
JB: Status emails felt a bit crowded recently. Need to make sure anything we do 
here isn't too fine grained, but also doesn't omit too many things.

AC: Effectively we want to maintain a status of features in the release. 
Perhaps a dedicated section in the community call where we can look at any 
updates. Only way this will work is to spend a small amount of time very 
regularly keeping it up to date - community call or similar venue seems 
appropriate.

OK: Last time this took half an hour
RPM: If we ensure it is just status and not technical detail discussion, this 
should be better
AC: Have to be quite brutal about stopping it going into technical detail. Keep 
it to a small amount frequently it should be less work than waiting several 
months to do lots of updates in one go.

RPM: Problem I have is knowing what to work on during the release, currently 
have to be quite reactive. E.g. could have put ASI in but then wouldn't have 
done any work on it.
Anthony Perard (AP): As a maintainer knowing what's important would help 
prioritise what to review more quickly.

Discussion around grooming and when things get dropped - AC: have to be quite 
strict about dropping things off which aren't making any progress.

JB: Do we know who will be doing release manager job after Oleksii?
OK: I can do it again

Alexander Merrit (AM): Do we want two release managers so one shadows the other 
to handover?
OK: Don't think this is necessary

AC: Release manager is supposed to be lightweight
RP: There are other things the release manager could do for community wide 
coordination. Should be a community wide plan driven by revenue for companies 
involved.
JB: We are not a company

RP: Example of companies joining projects to get certain things done, schedule 
might need to move to accommodate. Advisory board may need to fund a dedicated 
role to handle this sort of thing and coordinate the business side.

AC: Stefano is doing this on the safety side, which is one (large) part, but 
not everything.
RPM: Recently we've not been that bad about releases missing features - very 
few things that were very close but didn't make the cut.
AC/JB: Two at the moment (domctl stuff, ?something else?), so worse this 
release than it has been in past ones.

AM: Would it make sense to differentiate features that are 'reactive' vs what's 
good for the project as a whole?
AC: API/ABI example - doing more than what XenServer needs, as it it's a 
one-off opportunity
RP: Great example - shouldn't have to be done as a charity to help the project. 
Not sustainable.
AC: Some expectation/responsibility on maintainers as to work that has to be 
done (e.g. CI work). Xen has no developers who work for Xen, everyone works for 
a company who allows them to spend time on Xen.
RP: Companies should allocate an amount of hours to be directed by the release 
manager
JB: His opinion that won't work in open source
AM: Could we get money put in for specific items. Some projects seem ashamed to 
ask for money, is that the case here?
RPM: Difficult to find people with the right skills for Xen. Not the problem 
with money, but a problem with time.

RPM: Advisory board could maybe hire contractors through LF, but difficult.
RP: Go to contributing companies and say we want N hours of time from someone 
at company to improve release coordination, carves out a budget of time. 
Release manager goes from having zero power to maybe 1% power as they can now 
direct some work.

Actionable items:
- Grooming a list to discuss in community call
  Make clear to people they don't need to wait a month to update, can discuss 
on a thread
  Put the list on the agenda
  Formal tracking stays with release manager