tl;dr: Buildroot overrides should be restricted to releng members and packagers should use on-demand side-tags instead.
I'd like to ascertain whether there are any remaining use-cases for which buildroot overrides are preferable to (or necessary instead of) on-demand side-tags. We've had support for side-tags for some years now (my history-spelunking suggests 2020, but it might be longer).
Some of the advantages of side-tags over the old buildroot override approach:
1) The common buildroot for packages is not polluted. Historically, one would build a new library package, tag it into a buildroot override, then build the packages that depend upon it. During this time, the (possibly backwards-incompatible) package would remain in the common buildroot, potentially impacting other packages' builds. With side-tags, the updated libraries don't affect other builds until the side tag has completed and been merged into the main release. This action also ensures that the contents of the side-tag go through Bodhi and are properly reviewed, which helps avoid cases where the packager may not have been aware of other potential breakage.
2) Side tags are easy to abandon. If, in the middle of a large update, a major issue occurs (the change needs to be backed out or priorities shift and it cannot be completed in time), the side-tag can be either aborted or ignored until later. It doesn't require going through any effort to revert changes the way that buildroot overrides would.
3) Side tags make it much easier to submit multiple, related package updates together. Prior to side-tag support, including multiple packages in a single Bodhi update was a highly manual effort. Now, as long as they were built together in the side tag, they can be easily submitted together as a single update.
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up. Otherwise, my proposal that I plan to take to FESCo is to disallow the general use of buildroot overrides in favor of side tags. Buildroot overrides themselves wouldn't go away, but they'd be restricted to members of Fedora Release Engineering in exceptional situations.
Thank you in advance for your input.
Documentation on side-tags and multiple-package updates: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guid...
I am unaware of any remaining use cases for buildroot overrides that
are not covered by side tags
One use case that I sometimes encounter is requiring a newer version for a dependency, that is submitted to Bodhi with a side-tag. Since the build is in a side-tag, I can't access it without building into that specific side-tag. Also I can't stop the Bodhi Update just to add my own build. In this case, I need to create a buildroot override to be able to build my package in my own side-tag.
Sure, I can wait a couple of days for the update to land in stable but it's nice that I can also have a on-demand buildroot override that can speed things up.
On 22. 01. 24 19:07, Stephen Gallagher wrote:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
Every time somebody asks this, I say: Pull Requests CI
I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago.
It works in CentOS Stream, but not in Fedora.
Without that, I sometimes need to create a buildroot override to be able to test the the second package change before merging it.
On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 24 19:07, Stephen Gallagher wrote:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
Every time somebody asks this, I say: Pull Requests CI
I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago.
It works in CentOS Stream, but not in Fedora.
Without that, I sometimes need to create a buildroot override to be able to test the the second package change before merging it.
This sounds a lot more like a workaround than a use-case, but it's good to know about. So thank you.
Unfortunately, I feel like that workaround is dangerous, since it is putting untested code into the buildroot. I would like to see that get fixed properly with support for the side tags. In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception.
On 22. 01. 24 20:04, Stephen Gallagher wrote:
On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 24 19:07, Stephen Gallagher wrote:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
Every time somebody asks this, I say: Pull Requests CI
I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago.
It works in CentOS Stream, but not in Fedora.
Without that, I sometimes need to create a buildroot override to be able to test the the second package change before merging it.
This sounds a lot more like a workaround than a use-case, but it's good to know about. So thank you.
Yes, it is.
Unfortunately, I feel like that workaround is dangerous, since it is putting untested code into the buildroot.
In this case the PR-based CI has already passed for the build I add as a buidlroot override.
I would like to see that get fixed properly with support for the side tags.
I would like that very much. However, it seems it has not been a priority.
In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception.
How would that work? Would I ask FESCo every time I need to do it?
On Mon, Jan 22, 2024 at 2:11 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 24 20:04, Stephen Gallagher wrote:
On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 01. 24 19:07, Stephen Gallagher wrote:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
Every time somebody asks this, I say: Pull Requests CI
I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago.
It works in CentOS Stream, but not in Fedora.
Without that, I sometimes need to create a buildroot override to be able to test the the second package change before merging it.
This sounds a lot more like a workaround than a use-case, but it's good to know about. So thank you.
Yes, it is.
Unfortunately, I feel like that workaround is dangerous, since it is putting untested code into the buildroot.
In this case the PR-based CI has already passed for the build I add as a buidlroot override.
I would like to see that get fixed properly with support for the side tags.
I would like that very much. However, it seems it has not been a priority.
In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception.
How would that work? Would I ask FESCo every time I need to do it?
If it's something that a specific packager has justifiable cause to do on a regular basis, I think we could potentially grant them that privilege (at least until we get a proper solution in place). Or do you think this is the sort of thing where the number of people needing this access would be prohibitively high?
On 22. 01. 24 20:20, Stephen Gallagher wrote:
On Mon, Jan 22, 2024 at 2:11 PM Miro Hrončok mhroncok@redhat.com wrote:
In the meantime, if we otherwise disabled free-access buildroot overrides, this would definitely be grounds for granting an exception.
How would that work? Would I ask FESCo every time I need to do it?
If it's something that a specific packager has justifiable cause to do on a regular basis, I think we could potentially grant them that privilege (at least until we get a proper solution in place). Or do you think this is the sort of thing where the number of people needing this access would be prohibitively high?
Probably not.
* Stephen Gallagher:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
The overrides are more discoverable:
https://bodhi.fedoraproject.org/overrides/?expired=False
With side tags, you really have to know the name, or you won't be able to find it. On the other hand, you can just make your own and tag the builds into it, so creating yet another one isn't that much of a problem because they expire evenutally, just like overrides.
I think I may have used a buildroot override fairly recently (or created one for someone else to use), but I could have easily created a side tag instead. It just didn't occur to me. All things consdier, the side tag approach seems the way to go.
Thanks, Florian
On Mon, Jan 22, 2024 at 1:55 PM Florian Weimer fweimer@redhat.com wrote:
- Stephen Gallagher:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
The overrides are more discoverable:
With side tags, you really have to know the name, or you won't be able to find it. On the other hand, you can just make your own and tag the builds into it, so creating yet another one isn't that much of a problem because they expire evenutally, just like overrides.
What does that gain you, though? I'm not clear on the use-case here. Generally when there's a multi-packager effort going on for a side-tag, it's coordinated by mail or IRC between people. I'm not sure when you'd need to "discover" it.
* Stephen Gallagher:
On Mon, Jan 22, 2024 at 1:55 PM Florian Weimer fweimer@redhat.com wrote:
- Stephen Gallagher:
I am unaware of any remaining use cases for buildroot overrides that are not covered by side tags. If you know of any, please speak up.
The overrides are more discoverable:
With side tags, you really have to know the name, or you won't be able to find it. On the other hand, you can just make your own and tag the builds into it, so creating yet another one isn't that much of a problem because they expire evenutally, just like overrides.
What does that gain you, though? I'm not clear on the use-case here. Generally when there's a multi-packager effort going on for a side-tag, it's coordinated by mail or IRC between people. I'm not sure when you'd need to "discover" it.
It's been an issue once or twice when we relied more on ephemeral channels such as IRC (or just. But you are right, it does not matter much these days.
(For rediscovering your own side tags, there is “koji list-sidetags --mine”.)
Thanks, Florian
On Mon Jan 22, 2024 at 13:07 -0500, Stephen Gallagher wrote:
tl;dr: Buildroot overrides should be restricted to releng members and packagers should use on-demand side-tags instead.
Previous discussion from December 2022: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I believe we ultimately concluded that there were still some valid usecases for buildroot overrides. I'm not sure the situation has materially changed since then.
Il 22/01/24 19:07, Stephen Gallagher ha scritto:
tl;dr: Buildroot overrides should be restricted to releng members and packagers should use on-demand side-tags instead.
I'm fully in agreement with such proposal. Do note however that there's currently no way to restrict BRO usage in Bodhi, that's something that will need development.
I'd also like to propose to consider using side-tags together with temporary forks of Rawhide/release branches. That way, when a side-tag takes some time to completely rebuild a bunch of packages and fulfill its purpose, changes can be made to rawhide/stable branches without being impacted by any possible change introduced by the side-tag.
Mattia
Dne 23. 01. 24 v 8:58 Mattia Verga via devel napsal(a):
Il 22/01/24 19:07, Stephen Gallagher ha scritto:
tl;dr: Buildroot overrides should be restricted to releng members and packagers should use on-demand side-tags instead.
I'm fully in agreement with such proposal. Do note however that there's currently no way to restrict BRO usage in Bodhi, that's something that will need development.
I'd also like to propose to consider using side-tags together with temporary forks of Rawhide/release branches.
Originally, I was going to argue with this Stephen's statement:
Dne 22. 01. 24 v 19:07 Stephen Gallagher napsal(a):
- Side tags make it much easier to submit multiple, related package
updates together. Prior to side-tag support, including multiple packages in a single Bodhi update was a highly manual effort. Now, as long as they were built together in the side tag, they can be easily submitted together as a single update.
But yeah, the temporary branching (not forks necessarily) would certainly help to address this. Maybe it would even help with Miro's concerns about CI.
Vít
-
blinxen -
Florian Weimer -
Mattia Verga -
Maxwell G -
Miro Hrončok -
Stephen Gallagher -
Vít Ondruch