As mentioned on -devel I'd be happy to be the Board sponsor for this.

Happy to answer follow-up questions from the board meeting here

+1

I think this is a great idea. I have a couple concerns about implementation though.

First, I'd like us to have a clearer sense of what goes in vs what does not.
"Likely to be eventually merged" is a judgement call, not an impartial criteria.
I don't think we have to fully solve this to get the ball rolling, but I'd like us to put some more thought into it.
My concern is that people are going to get upset about what is or isn't pulled in.

Second, I'm a little concerned about possible NVR corner cases.
Using a different dist tag might not always work as desired.
For example, if a pending MR bumps the package to a new version, and then stream proceeds to ship updates for the old version (or a not-as-new version), then the fasttrack user will be missing these stream updates.
This is a simple example, but there could be more esoteric issues lurking across the breadth of specfiles.

I'd love some sort of workflow specified for what happens if the merge request is closed out but not merged.

+1

I think this is a great idea. I have a couple concerns about implementation though.

First, I'd like us to have a clearer sense of what goes in vs what does not.
"Likely to be eventually merged" is a judgement call, not an impartial criteria.
I don't think we have to fully solve this to get the ball rolling, but I'd like us to put some more thought into it.
My concern is that people are going to get upset about what is or isn't pulled in.

I think we can emphasize that this is a "best effort", as is everything done by interested volunteers, and that SIG members will prioritize fixing packages that they care about. And that if people want a package fixed that no one has the bandwidth for, they are welcome to join and work on them!

• with the caveat that we are not trying to build an empire here and we /want/ our packages to expire

Second, I'm a little concerned about possible NVR corner cases.
Using a different dist tag might not always work as desired.
For example, if a pending MR bumps the package to a new version, and then stream proceeds to ship updates for the old version (or a not-as-new version), then the fasttrack user will be missing these stream updates.
For this particular case - I think we should start on the conservative side and never bump version

This is a simple example, but there could be more esoteric issues lurking across the breadth of specfiles.

Definitely. I think we basically should require these to be considered each time a new package is being proposed - e.g. at least one other SIG member has to ack before a package is built.

I'd love some sort of workflow specified for what happens if the merge request is closed out but not merged.

Worst case, because we focus on specific fixes, the main Stream package will overtake the fast track one in NEVRA - when that happens I think the person building it in the SIG needs to decide if they should try again (rebasing the changes) or just retire the package.

We should probably do a cleanup of all packages periodically too, I could imagine doing it every time a point release is out is a good cadence.

It's a similar workflow to what we in practice do in Hyperscale, except for most Hyperscale packages "rebase" is the only option.

This may have been asked and answered already but how will you deal with version numbers? In the case above you mention retiring a package and using the main one. Will you use a specific naming and numbering convention? So for example using package puppy as an example in the following scenario Fast track has package puppy-01.23 and main package is puppy-01.22. Fast track is retired but the main package has a lower version number.

One more workflow bit that just occurred to me - each package we have in fast track should have an open issue associated with it, which is closed only when the package is retired (and point to the MR filed). That will make it easier to have visibility and when performing bulk cleanup.

This may have been asked and answered already but how will you deal with version numbers? In the case above you mention retiring a package and using the main one. Will you use a specific naming and numbering convention? So for example using package puppy as an example in the following scenario Fast track has package puppy-01.23 and main package is puppy-01.22. Fast track is retired but the main package has a lower version number.

I missed answering this, sorry. At the beginning we don't plan on bumping version number - stick to packages where the fix can be backported.

In case we do need to bump the version number - this likely needs some indication from the Stream / RHEL maintainers that the new version will land in EL/Stream soon-ish (say by the next minor release) and we should probably start with revision 0.x

This was approved in the 2025-03 board meeting as the CentOS Proposed Updates SIG.