Update branching documentation after Fedora 39 branching #5089
Conversation
The localization branch is called f<version>, not fedora-<version>.
|
/kickstart-test --testtype smoke |
docs/release.rst
Outdated
| 'fedora-38': [ | ||
| 'fedora-38', | ||
| ], | ||
| '_manual': [ | ||
| 'fedora-39': [ | ||
| 'fedora-39', |
There was a problem hiding this comment.
I don't think we want to adjust this each branching.
| Lastly it is necessary to set up updated l10n commit hash - check the commit hash of the ``anaconda-l10n`` repo, | ||
| the one where the new f<version> folder has been added and put the hash to the ``GIT_L10N_SHA`` variable in the | ||
| ``po/l10n-config.mk`` file. | ||
|
|
||
| This is necessary for the Web UI related translation pinning to work & l10n branching checks to pass. | ||
|
|
There was a problem hiding this comment.
This is not necessary to be done manually. Only case is if you doing release before the anaconda-l10n automation is started. At least I would expect that.
This is definitely not something we want to do manually - copying hashes.
There was a problem hiding this comment.
If you keep the hash the same, it will fail the branching check, because the directory is literally missing. Also all subsequent rpm builds etc.... you get the idea.
To do this "automatically", run make -f Makefile.am bump-l10n-sha which will change the file. You still need to commit it manually after that.
The issue - which needs more thought, perhaps - is that the cockpit tests are not guaranteed to work after this, because they do not run on the branch itself. But maybe that's overthinking it, and making tests (and generally CI) succeed are separate steps afterwards?
There was a problem hiding this comment.
On a second thought, yes, instead of the manual steps, just run the makefile target, it will do the same.
The CI success status is a secondary concern throughout the whole process as documented, so if we want to address that, it would be another effort, probably for a less hectic branching.
docs/release.rst
Outdated
| Container rebuilds after branching | ||
| ---------------------------------- | ||
|
|
||
| Container rebuilds currently do not happen automatically after branching. So Do not forget to rebuild |
There was a problem hiding this comment.
Typo So Do not... -> So do not.
Looks like the _manual bit is not there anymore.
While this is usually automated, it needs to be done manually right after branching.
This should make it harder to forget to do that.
In the future it would be best to either automatically trigger the rebuild or extend this section with instructions about how to perform the procedure or at least information which containers should be rebuilt.
M4rtinK
force-pushed
the
master-f39_fix_docs
branch
from
eef2729
to
aba6a3a
Compare
|
/kickstart-test --waive webui only |
Dragging the docs back to reality - Fedora 39 edition. ;-)