SOP: how to build a hotfix by xsuchy · Pull Request #4056 · fedora-copr/copr

xsuchy · 2025-12-08T16:34:38Z

No description provided.

xsuchy · 2025-12-08T16:35:20Z

Please comment about the last section.

github-actions · 2025-12-08T16:57:42Z

Pull Request validation

Failed

🔴 Review - Missing review from a member (2 required)

Success

🟢 CI - All checks have passed

praiskup · 2025-12-09T07:34:38Z

doc/how_to_build_hotfix.rst

+
+Create hotfix branch ($DATE is date of last release):
+
+    git branch hotfix-$DATE


Please also git checkout ..., otherwise we git reset the main branch later.

do you mean by this rebasing on the upstream/main before creating the hotfix branch, right?

This is a description for creating the branch. This part can be (should be) skipped on subsequent runs. As written in the first paragraph.

The git checkout is still missing here.

??? Can you write that command? I have no idea what you mean.

git branch hotfix-$DATE git checkout hotfix-$DATE

praiskup · 2025-12-09T07:35:53Z

doc/how_to_build_hotfix.rst

+
+optionally you can change even:
+
+    builder = tito.builder.UpstreamBuilder


Not sure if I should commit those changes?

If so, can you please add the command with already prepared commit message, so that we can easily copy-paste it from the docs?

nod I added git-commit

praiskup · 2025-12-09T07:43:27Z

doc/how_to_build_hotfix.rst

+
+    git branch hotfix-$DATE
+
+Return in history to commit that points to latest commit tagging packages for the release:


This might be a bit hard choice, not sure, we'll see in practice. Consider history like (last commit goes first)

aaa: to-be-hotfixed commit to python-copr

bbb: irrelevant commit for copr-backend

ccc: [python-copr] tagged

ddd: to-be-hotfixed commit to copr-backend

eee: [copr-backend] taged

fff: [copr-frontend] tagged

000: other commit covered by subsequent tags

Now, I want a hot-fix branch, and have a hot-fix for both [python-copr] and [copr-backend]. Where do I start?

can't we just cherry pick the relevant commits instead?

Addressed by:
If multiple packages were tagged during the release, choose the commit related to latest package in the release

praiskup · 2025-12-09T07:46:39Z

doc/how_to_build_hotfix.rst

+and walk the directories of packages listed. For every SPEC file make sure that `Version` tag has `^hotfix` at the end.
+This ensure that the hotfix version is higher than any rebuild in Fedora.
+
+    1.1-5 < 1.1^hotfix-1


Can we use . instead of ^?

praiskup · 2025-12-09T07:49:36Z

doc/how_to_build_hotfix.rst

+
+or
+
+Create hotfix project in Copr itself. Enable this repo in production. Build there the hotfix and install from Copr.


At this point in time, we have those files most likely patched in production, vim-modified, I know -- 🥇.
Anyway, that's the most convenient thing to do and I doubt it makes any sense to change our practice; IOW we are not in hurry, we can simply wait till the package gets to infra tags -- and then do a no-brainer dnf update.

Anyway, that's the most convenient thing to do and I doubt it makes any sense to change our practice;

meaning of this is not creating this SOP? or is it encouragement to follow the https://docs.pagure.org/copr.copr/how_to_release_copr.html#build-packages-for-production ?

tbh I am against both, current status is definitely not ideal, yep. And having it released to fedora bring no benefits in my view... only adding boring process at the end of creating of the hotfix... is there really some big difference for us to have the hotfix directly to fedora that makes it no-brainer? Is there some benefit I am missing?

I meant that even with this (a go-to, really) SOP, you can still edit with vim, but then you must provide a hot-fix package and simply run dnf update to apply it (in an hour or so..).

praiskup · 2025-12-09T07:51:49Z

Thank you very much for the document, @xsuchy 🚀

FrostyX · 2025-12-11T23:14:10Z

doc/how_to_build_hotfix.rst

@@ -0,0 +1,75 @@
+.. _how_to_build_hotfix:


We should probably link this from the maintenance_documentation.rst

nikromen · 2025-12-22T14:18:48Z

we could test this on #4092 after new year to unblock packit/packit-service#2907 :)

nikromen · 2025-12-22T14:31:27Z

doc/how_to_build_hotfix.rst

+Edit `tito.props` to:
+
+    tagger = tito.tagger.ReleaseTagger
+
+optionally you can change even:
+
+    builder = tito.builder.UpstreamBuilder


I'd love to (just personal wish) have here short description (a few words) about what is the use case when I should include also the second (builder) option

+1, would "Check man(5) releasers.conf" be enough?

xsuchy · 2026-01-05T11:48:14Z

Ready for review.

praiskup · 2026-01-07T07:56:25Z

LGTM, just please mention that we need to switch into the newly crated branch.

praiskup · 2026-01-11T12:38:51Z

doc/how_to_build_hotfix.rst

+
+Tag every package that was listed in the step above:
+
+    tito tag


here should be tito tag --user-version 1.1.hotfix

No.

This is handled by:

For every SPEC file make sure that Version tag has .hotfix at the end.

when you add it to spec file, then you can just simply tito tag.

Weird. Isn't tito tag responsible for overriding Version, though?

I mean, I used --use-version recently with a hotfix: 7975ceb

Without that, I'd expect Tito to take what's inside .tito/packages/copr-backend and auto-bump.

OK, tito reads specfile value first. And we used hotfix.0 as the starting point. LGTM

praiskup · 2026-01-12T14:09:05Z

doc/how_to_build_hotfix.rst

+    tito report --untagged-commits
+
+and walk the directories of packages listed. For every SPEC file make sure that `Version` tag has `.hotfix` at the end.
+This ensure that the hotfix version is higher than any rebuild in Fedora.


What if we need to have a subsequent hotfix? We can't just bump Release, we need to do something about it in Version, e.g., hotfix.2?

xsuchy marked this pull request as draft December 8, 2025 16:34

github-actions bot added the pr/missing-review label Dec 8, 2025

praiskup reviewed Dec 9, 2025

View reviewed changes

praiskup mentioned this pull request Dec 9, 2025

Create usable manual for releasing copr's rpms #4054

Open

FrostyX reviewed Dec 11, 2025

View reviewed changes

nikromen reviewed Dec 22, 2025

View reviewed changes

xsuchy force-pushed the hotfix branch from 0dd5d59 to 6f76841 Compare January 5, 2026 11:47

xsuchy marked this pull request as ready for review January 5, 2026 11:48

praiskup reviewed Jan 11, 2026

View reviewed changes

praiskup reviewed Jan 12, 2026

View reviewed changes

SOP: how to build a hotfix

a72588f

xsuchy force-pushed the hotfix branch from 6f76841 to a72588f Compare January 13, 2026 13:33

praiskup approved these changes Jan 13, 2026

View reviewed changes

praiskup merged commit 9a298dd into fedora-copr:main Jan 13, 2026
6 checks passed


		Create hotfix branch ($DATE is date of last release):

		git branch hotfix-$DATE


		optionally you can change even:

		builder = tito.builder.UpstreamBuilder


		git branch hotfix-$DATE

		Return in history to commit that points to latest commit tagging packages for the release:


		or

		Create hotfix project in Copr itself. Enable this repo in production. Build there the hotfix and install from Copr.


		Tag every package that was listed in the step above:

		tito tag

Conversation

xsuchy commented Dec 8, 2025 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xsuchy commented Dec 8, 2025

Uh oh!

github-actions bot commented Dec 8, 2025

Pull Request validation

Failed

Success

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

praiskup commented Dec 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikromen commented Dec 22, 2025

Uh oh!

nikromen Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xsuchy commented Jan 5, 2026

Uh oh!

praiskup commented Jan 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

praiskup Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

xsuchy commented Dec 8, 2025 •

edited by github-actions bot

Loading

nikromen Dec 22, 2025 •

edited

Loading

praiskup Jan 12, 2026 •

edited

Loading