Would locking the build requests really solve this issue?
I feel that we actually need a lock to source code. At least to a branch.

See this example:
Let's say package foo is being updated and requires rebuilding bar.
foo's source is updated and it is rebuilt in a side tag.
Then bar gets a release bump in the source code and a build is requested in a side tag, but the build fails requiring a minor change in bar.
That means bar will need to be updated again.

If another developer changes bar between the first and the second change there will be a conflict.

I'm sorry, I don't really understand the situation you're describing, or how it relates to the RFE here. Making sure package sources are buildable is an orthogonal issue to making sure builds are done in the correct environment.

My initial take is that this is highly specific to particular workflows and probably not a priority to implement in Koji itself.

A global lock seems like an overly big hammer for the problems you are worried about. Scratch builds shouldn't be an issue, and arguably builds against other tags shouldn't be either.

You could probably get close enough simply by adjusting tagging policy

Its specific to specific workflows, yes, but the affected workflow is the default and recommended way to handle multi-build updates in Fedora ... not sure if tagging policy can solve this?

Also, the first option for implementing this kind of feature should address exactly the two "not such a big hammer please" things you worried about, shouldn't it?

I'm sorry, I don't really understand the situation you're describing, or how it relates to the RFE here.

@decathorpe In that case, I'd appreciate if you could pose questions.

Making sure package sources are buildable is an orthogonal issue to making sure builds are done in the correct environment.

This is not the point of my first comment. What I'm trying to point out is that, in order to prevent the issues that happened during the Python 3.12 rebuilds the following part:

... it is crucial that packages that are involved are not built outside those build targets

Should be rewritten to:

... it is crucial that packages that are involved do not have their source code modified by other people during the lock window.

I'm sorry, I don't really understand the situation you're describing, or how it relates to the RFE here.

@decathorpe In that case, I'd appreciate if you could pose questions.

I read your example again, and in most cases, the RFE I'm asking for would still improve workflows in the majority of cases. Packagers pushing changes to dist-git that don't build is not specific to the issue I'm trying to address here.

Making sure package sources are buildable is an orthogonal issue to making sure builds are done in the correct environment.

This is not the point of my first comment. What I'm trying to point out is that, in order to prevent the issues that happened during the Python 3.12 rebuilds the following part:

... it is crucial that packages that are involved are not built outside those build targets

Should be rewritten to:

... it is crucial that packages that are involved do not have their source code modified by other people during the lock window.

I see what you mean now, but that's a step ahead of what I'm trying to solve here. I'd just prevent new builds if they happen to be requested for the "wrong" target. Preventing pushes to dist-git is not necessarily required, since those commits can always be reverted without consequences if there has been no build for the reverted commit.

We also expect package maintainers to fix Python 3.12 related issues. The "it is crucial that packages that are involved do not have their source code modified by other people during the lock window" is not quite what we would need.

We've just had a similar experience with FFmpeg bump to 8 and associated rebuilds (just ~90), which conflicted with packages like chromium, cef, and others (e.g. KDE Gear stack). Preventing regular rawhide build of the packages which were already in the FFmpeg 8 side-tag is exactly what would've helped avoid the conflicts and additional rebuilds in the side-tag. Preventing dist-git pushes would've been the wrong thing to do.

Would locking the build requests really solve this issue?

Yes.

I feel that we actually need a lock to source code. At least to a branch.

I disagree.

See this example:
Let's say package foo is being updated and requires rebuilding bar.
foo's source is updated and it is rebuilt in a side tag.
Then bar gets a release bump in the source code and a build is requested in a side tag, but the build fails requiring a minor change in bar.
That means bar will need to be updated again.

If another developer changes bar between the first and the second change there will be a conflict.

This is actually normal and expected to happen. I had a few cases of this and I always rebased my "rebuild for FFmpeg 8" commits on top of rawhide HEAD just before submitting the actual build. I'm not sure what your point is/was.

My initial take is that this is highly specific to particular workflows and probably not a priority to implement in Koji itself.

This "particular workflow" is the recommended workflow for incompatible ABI updates. I'd say it should be a priority because we do a lot of these in rawhide.

A global lock seems like an overly big hammer for the problems you are worried about. Scratch builds shouldn't be an issue, and arguably builds against other tags shouldn't be either.

I agree scratch builds are out of scope and I'm not sure what you mean by "global" lock. We need a branch-specific lock allowing regular package builds for a set of packages currently in a specific side-tag to happen only in that side-tag and no other.

You could probably get close enough simply by adjusting tagging policy

If that can be achieved with a "tagging policy", whatever that means, then I'm fine with that.

I'm not sure what your point is/was.

@rathann If you have questions, please ask them.
By the way, see decathorpe's proposal to work around the issue I had raised:

I see what you mean now, but that's a step ahead of what I'm trying to solve here. I'd just prevent new builds if they happen to be requested for the "wrong" target. Preventing pushes to dist-git is not necessarily required, since those commits can always be reverted without consequences if there has been no build for the reverted commit.

Can someone direct me to the details of the actual problem(s) this rfe claims to be the solution for?

I am still of the opinion that this should be solved either by altering the workflow outside of Koji, or updating policy (or both).

I'm not sure what your point is/was.

@rathann If you have questions, please ask them.

The question is: what does your example have to do with the issue @decathorpe and I are describing? I don't see the relevance.

By the way, see decathorpe's proposal to work around the issue I had raised:

I see what you mean now, but that's a step ahead of what I'm trying to solve here. I'd just prevent new builds if they happen to be requested for the "wrong" target. Preventing pushes to dist-git is not necessarily required, since those commits can always be reverted without consequences if there has been no build for the reverted commit.

Again, I fail to see what you mean here. I don't understand what issue you had raised or how what @decathorpe wrote works around anything related to the original issue.

Can someone direct me to the details of the actual problem(s) this rfe claims to be the solution for?

As I said: we built some packages in a side-tag. Meanwhile, other packagers modified and built some of the same packages directly into rawhide, outside the side tag. That caused bodhi to refuse to push the builds from the side-tag as an update.

To fix the above, currently, one has to bump and rebuild the conflicting packages again inside the side-tag and refresh the build list in bodhi and resubmit the update.

I am still of the opinion that this should be solved either by altering the workflow outside of Koji, or updating policy (or both).

How?

The question is: what does your example have to do with the issue @decathorpe and I are describing? I don't see the relevance.

I described a more general concurrency problem that cannot be solved just by blocking package builds. Putting it another way: the critical section starts when commit reaches the git repository and ends with a package reaching stable.

With that said, I completely agree with decathorpe that we can work around it if we have a way to block package builds.

Thanks for asking this question!

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3847

Please continue any further discussion there.