How to contribute to an older branch - You need 'Create Change' rights message

[aha_1980]

Hi @MelOzone,

You always push your changes to dev, so git push gerrit HEAD:refs/for/dev. After they are submitted there, they can be cherry-picked to the stable branches. This is done automatic by a Pick-to: line directly above the Change-Id:. Example: Pick-to: 6.12 6.11 6.10 6.8.

Best regards

[JKSH]

Thank you for your contribution!

@MelOzone said in How to contribute to an older branch - You need 'Create Change' rights message:

Unfortunately, I've read about git hooks after I've made the commits in my local branch, so commit comments are "freeform" (but descriptive).

In that case, your commit message is most probably missing the Change-Id field. Please install the git hooks and then amend your commit. This should trigger the hooks to insert a Change-Id.

targeting branch 6.10

The 6.10 branch is no longer accepting any commits. Please see https://contribute.qt-project.org/quips/16 for what is accepted in each category of branches. Currently,

• 6.12 and 6.11 are stable branches
• 6.8 is an LTS branch in strict mode

So, if your patch fixes a crash, add Pick-to: 6.12 6.11 6.8 to your commit message. If it's a non-critical bugfix, add Pick-to: 6.12 6.11. If it's a new feature, don't cherry-pick at all.

And as @aha_1980 said, you must push with git push gerrit HEAD:refs/for/dev

[MelOzone]

@JKSH Thanks a lot! I considered amend but
a) I have no experience using it
b) I am not familiar with how hooks work and wasn't sure that they would "pick up" the amend operation.

Since your advice points out that they will, I'll meditate on the docs and try to do just that.

@aha_1980 Your note about always pushing to dev is, I believe, very important, especially to newcomers like me. I saw no mention of that previously. Can you add this to the wiki? Qt has a massive amount of documentation; I try my best to follow it, but it isn't easy.

@JKSH said in How to contribute to an older branch - You need 'Create Change' rights message:

So, if your patch fixes a crash, add Pick-to: 6.12 6.11 6.8 to your commit message. If it's a non-critical bugfix, add Pick-to: 6.12 6.11. If it's a new feature, don't cherry-pick at all.

It is a new feature (I've implemented a small part of SVG 2.0 specification), but it relies on 6.10 structure and will absolutely need changes to be merged into dev (6.12 changes the memory management of SVG attributes under the hood). I can't do it on my side since 6.10 is the latest version I can locally build, so I hoped that it would be merged into 6.10 with minimal effort, then forward-ported to dev to minimize the load on maintainers.
If cherry-picking the version and adapting the code for dev by the Qt automated systems and code reviewers is not an issue, it's fine by me.

[JKSH]

@MelOzone said in How to contribute to an older branch - You need 'Create Change' rights message:

@JKSH Thanks a lot! I considered amend but
a) I have no experience using it
b) I am not familiar with how hooks work and wasn't sure that they would "pick up" the amend operation.

Since your advice points out that they will, I'll meditate on the docs and try to do just that.

You're welcome!

The instructions for (b) are at https://wiki.qt.io/Setting_up_Gerrit#Setting_up_git_hooks

For (a), good GUI clients should make amending reasonably prominent. If you use the console, the command is git commit --amend. You could simply update the text of your commit message (and then amend again to change it back if you wish).

@aha_1980 Your note about always pushing to dev is, I believe, very important, especially to newcomers like me. I saw no mention of that previously. Can you add this to the wiki? Qt has a massive amount of documentation; I try my best to follow it, but it isn't easy.

Understandable.

Please see https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change? which says, "All new features go into dev" It does mention an exception where pushing to a non-dev branch is allowed, but that doesn't apply here.

It is a new feature (I've implemented a small part of SVG 2.0 specification), but it relies on 6.10 structure and will absolutely need changes to be merged into dev (6.12 changes the memory management of SVG attributes under the hood). I can't do it on my side since 6.10 is the latest version I can locally build, so I hoped that it would be merged into 6.10 with minimal effort, then forward-ported to dev to minimize the load on maintainers.
If cherry-picking the version and adapting the code for dev by the Qt automated systems and code reviewers is not an issue, it's fine by me.

Unfortunately, the workflow in Qt is the other way round: Changes must be merged into dev first, then cherry-picked to older branches if appropriate.

Also, your feature will need to work with the changed memory management so testing on 6.12 or dev is advisable.

May I ask why you aren't able to build 6.11/6.12/dev? At the very least, you can install Qt 6.12.0-beta2 from the Qt Online Installer and then use it to build qtsvg.git:

mkdir build
cd build
 ~/Qt/6.12.0/gcc_64/bin/qt-configure-module /path/to/qtsvg

[MelOzone]

@JKSH
Funnily enough, I'm so used to VSCodium's Git tab that it took me a while to figure out why the hooks don't work. They are only triggered if git commands are run from the terminal.
I know that mature developers use the terminal, but I never claimed to be mature.

Amending worked; the Early Warning hook output is clean now.

@JKSH said in How to contribute to an older branch - You need 'Create Change' rights message:

Also, your feature will need to work with the changed memory management so testing on 6.12 or dev is advisable.

May I ask why you aren't able to build 6.11/6.12/dev? At the very least, you can install Qt 6.12.0-beta2 from the Qt Online Installer and then use it to build qtsvg.git:

Sure. I have an old machine (5+ years old at this time, likely even 10+) which runs Fedora 44. The latest stable release of QtBase for it is 6.11.1. QtSvg 6.11 requires at least QtBase 6.11.2 to compile.
My initial plan was to build at least QtBase 6.11.1 bundled with my QtSvg. That required downgrading several packages, and now the Qt Online Installer doesn't even start.
I can probably clone the latest QtBase repo and try to build it on my own, but it won't be easy for a newbie and, by my estimation, will take at least a few hours on my hardware. Which is problematic due to power outages and missile strikes: I don't have backup power sources to keep my rig running for long if the main grid is down.

[MelOzone]

Update: I've managed to reupdate the system packages and get the Qt Online Installer to work again.

The latest version it offers is Qt 6.12.0-beta (or something), which is what I chose. I've modified my CMakeUserPresets to use the custom Qt installation path:

{
    "version": 8,
    "configurePresets": [
        {
            "name": "GCC",
            "displayName": "GCC (Qt 6.12.0-beta)",
            "description": "Using compilers: C = /usr/bin/gcc, CXX = /usr/bin/g++. Targets Qt 6.12.0-beta (latest public).",
            "binaryDir": "${sourceDir}/../qtsvg-build/${presetName}",
            "generator": "Ninja",
            "cacheVariables": {
                "CMAKE_INSTALL_PREFIX": "/usr/local",
                "CMAKE_C_COMPILER": "/usr/bin/gcc",
                "CMAKE_CXX_COMPILER": "/usr/bin/g++",
                "CMAKE_EXPORT_COMPILE_COMMANDS": "ON",
                "BUILD_SHARED_LIBS": "ON",
                "QT_BUILD_EXAMPLES":"OFF",
                "QT_BUILD_STANDALONE_EXAMPLES":"OFF",
                "QT_BUILD_TESTS":"ON",
                "CMAKE_BUILD_TYPE": "Debug",
                "CMAKE_PREFIX_PATH": "<path>/Qt6-12b/6.12.0/gcc_64/lib/cmake/Qt6/",
                "CMAKE_PROGRAM_PATH": "<path>/Qt6-12b/6.12.0/gcc_64/libexec"
            }
        }
    ]
}

This wasn't enough (dev branch of QtSvg requires Qt 6.13.0, which is not included in the installer), so the only option I saw was circumventing the check entirely:
cmake --preset="GCC" -DQT_NO_PACKAGE_VERSION_CHECK=TRUE

This allowed me to complete CMake reconfig. CMake build, however, still fails as early as step one:
[1/93] Running syncqt.cpp for module: QtSvg FAILED: [code=1] src/svg/Svg_syncqt_timestamp include/QtSvg/QtSvgVersion include/QtSvg/qtsvgversion.h src/svg/Svg.version.private_content include/QtSvg/QtSvg ... /qtsvg-build/GCC/src/svg && /usr/lib64/qt6/libexec/syncqt @ ... Unknown argument: -spiIncludeDir [4/93] Generating ../../mkspecs/modules/qt_lib_svg_private.pri ninja: build stopped: subcommand failed.

As far as I understand, CMake tries to use the system version of syncqt because the output references /usr/lib64/qt6/libexec/syncqt.
Note the CMAKE_PROGRAM_PATH in the CMakeUserPresets - I tried to somehow enforce using syncqt from the custom installation, doesn't help.
I've also tried patching PATH with the relevant location before running cmake — doesn't help either.

Any advice?

[JKSH]

@MelOzone said in How to contribute to an older branch - You need 'Create Change' rights message:

I'm so used to VSCodium's Git tab that it took me a while to figure out why the hooks don't work. They are only triggered if git commands are run from the terminal.

That sounds strange to me. I would've expected the GUI to call the same git commands as the terminal -- the only difference is that the terminal requires the user to know the exact commands to use, while the GUI doesn't.

Amending worked; the Early Warning hook output is clean now.

👍

I have an old machine (5+ years old at this time, likely even 10+) which runs Fedora 44.

This part should be fine. My current workstation is 9+ years old, running Windows 10, and it has successfully built several different versions of Qt in recent weeks.

will take at least a few hours on my hardware. Which is problematic due to power outages and missile strikes: I don't have backup power sources to keep my rig running for long if the main grid is down.

I'm sorry to hear that... I yearn for a future where people no longer wage war with each other.

@MelOzone said in How to contribute to an older branch - You need 'Create Change' rights message:

This wasn't enough (dev branch of QtSvg requires Qt 6.13.0, which is not included in the installer), so the only option I saw was circumventing the check entirely:
cmake --preset="GCC" -DQT_NO_PACKAGE_VERSION_CHECK=TRUE

This allowed me to complete CMake reconfig. CMake build, however, still fails as early as step one:
`[1/93] Running syncqt.cpp for module: QtSvg
FAILED: [code=1] src/svg/Svg_syncqt_timestamp include/QtSvg/QtSvgVersion include/QtSvg/qtsvgversion.h src/svg/Svg.version.private_content include/QtSvg/QtSvg
...
/qtsvg-build/GCC/src/svg && /usr/lib64/qt6/libexec/syncqt @
...

Any advice?

The Qt Online Installer would have installed Qt Creator too. You should be able to use it to build small modules like Qt SVG without fiddling with any configurations.

1. For simplicity, checkout the 6.12 branch of qtsvg.git
2. Launch the Qt Online Installer's copy of Qt Creator
3. Click "File" > "Open Project..." and select qtsvg/CMakeLists.txt
4. When prompted, select your Qt 6.12 kit, and specify a Release build
5. Click "Build" > "Build Project"

Does this build successfully?

[MelOzone]

@JKSH said in How to contribute to an older branch - You need 'Create Change' rights message:

Does this build successfully?

Apparently, yes, this way works. I've never used Qt Creator before (Qt 6.12.0-beta2 requires choosing a "custom installation" where it isn't included by default).
(except the "Release" part in p.4 — it didn't ask that, or I've missed it, or it possibly picks the presets from my CMakeUserPresets (which contain

"CMAKE_BUILD_TYPE": "Debug",

).

I've built it with tests and managed to run a couple (hopefully, Creator runs them against the correct version).
What do you propose next? I can probably integrate my changes into QtSvg 6.12 on my own. Will this build be suitable to push for code review?

[JKSH]

@MelOzone said in How to contribute to an older branch - You need 'Create Change' rights message:

I've built it with tests and managed to run a couple (hopefully, Creator runs them against the correct version).

It's possible that you've been running the pre-built version of Qt SVG provided by the installer. After you've built your library, back up ~/Qt/6.12.0/gcc_64/lib/libQt6Svg.so.6.12.0 (and maybe ~/Qt/6.12.0/gcc_64/lib/libQt6SvgWidgets.so.6.12.0, depending on where exactly your changes are) and replace it with the copy that you've built.

After that, use Qt Creator to load, build, and run an application using your Qt 6.12.0 kit. This should cause the app to load the pre-built Qt Core and your custom-built Qt SVG.

Here's one way to verify that your *.so file is being used: Insert a qDebug() message into the QSvgWidget constructor, and check that your message gets printed when your app creates a QSvgWidget.

What do you propose next? I can probably integrate my changes into QtSvg 6.12 on my own. Will this build be suitable to push for code review?

I suggest:

1. Commit your changes on top of v6.12.0-beta2 (you could cherry-pick your existing commit from the 6.10 branch, or edit the code and create a new commit)
2. Test your changes as above, using the Qt 6.12.0 kit
3. Cherry-pick or rebase your commit to the dev branch, to verify that there are no merge conflicts
4. Push to refs/for/dev

Assuming that there have been no major changes between 6.12.0-beta2 and dev, this has a good chance of working. I use this method myself when I want to avoid having to build all of Qt from scratch. It works most of the time, but there have been some cases where a change works on the latest release but not on dev (because someone had recently pushed a conflicting change, for example).

[MelOzone]

@JKSH I've made some progress - merged my changes from QtSvg 6.10 into 6.12. Also tried rebase (on a separate copy), but rebasing is a separate sorcery skill I clearly do not possess at the moment.

The merged version builds, but my CMakeUserPresets got lost somewhere in the merging, and now Qt Creator builds everything in the repo/build directory. A minor inconvenience, but tolerable.

Running tests and examples against the new build (and ensuring they are run against the new build) needs more time. I remember trying my previous CMake build with a custom LD_LIBRARY_PATH to ensure it uses the right stuff. Maybe it will be applicable in this case as well. Qt Creator likely has env variables somewhere in the Project settings, haven't explored those yet. The AI that I poke with different stupid questions also suggests that I can try
ldd /path/to/your/example | grep Svg to verify that the example/test will use the correct library before running it.
I'll circle back to this thread when I have more info to share.