Qt5PatchCollection: Difference between revisions

Latest revision as of 11:50, 5 March 2022

What's this?

This is a set of git repositories based on the last public commits available for Qt 5.15 branches with a curated collection of patches on top to ensure open source products can be used comfortably until users transition to their Qt 6-based ports.

Which patches does it include?

This collection of patches includes patches that fix at least one of the following:

Security issues
Crashes
Functional defects

We only include patches that have been approved upstream in the Qt project. If a patch cannot be merged upstream for technical reasons (e.g. the class no longer exists), it can also be merged.

The patches to merge will be decided based on their relevance towards Open Source products and their viability.

How do I get a patch merged?

To get a patch merged you must open a Merge Request against the kde/5.15 branch on the corresponding repository in https://invent.kde.org/qt/qt, describing the change as well as the reason it should be merged (e.g. by referencing a relevant defect report in an open source product). Also required is a reference to where it was approved upstream within https://codereview.qt-project.org.

Note that this is gitlab (not gerrit), but without the usual permissions for KDE developers. So everyone must fork the repo first.

Also note that the repo is synced with upstream qt (several times a day), so the commit you want to backport will be in there already, in dev or a 6.x branch, you can just cherry-pick it (with the option "-x"). Then push to your fork, and create a merge request for branch kde/5.15.

Who decides if a patch gets merged?

There is a group of curators for this patch collection that will have the final say on whether a patch is merged or not.

How does it work?

Here we have a version of Qt 5 that includes fixes for the issues we have found impacted the use of open source products. These patches can be obtained with the following command:

   git format-patch v5.15.3-lts-lgpl..origin/kde/5.15

What is the license of the patches?

The patches will be licensed under the same licenses as the Qt Open Source edition module they apply against.

How do I get this integrated in my distribution?

These patches can be obtained with the following command:

   git format-patch v5.15.3-lts-lgpl..origin/kde/5.15

They can then be integrated using the tooling specific to your distribution.

Will there be releases?

No, we will not make releases of the patch collection.

Can I contribute new features?

No, this is strictly a stability patch collection.

For how long will this be maintained?

We expect the patch collection to be maintained for as long as is required to serve users of Qt 5.15-based Open Source products, but to be ultimately made obsolete by the adoption of Qt 6 when Qt 6 enables superior Open Source product development.

I do not want to sign the Qt Contribution Agreement, can I still contribute patches?

As mentioned, we generally only accept patches if they have been merged upstream first. The only circumstance in which we may accept a patch not covered by the Qt Contribution Agreement is if it does not apply upstream for technical reasons.

I am a KDE developer, can I do direct pushes?

No, this project is a bit special and does not follow the same contribution rules the rest of KDE repositories.

@@ Line 17: / Line 17: @@
 === How do I get a patch merged? ===
-To get a patch merged you must open a Merge Request on the corresponding repository in https://invent.kde.org/qt/qt, describing the change as well as the reason it should be merged (e.g. by referencing a relevant defect report in an open source product). Also required is a reference to where it was approved upstream within https://codereview.qt-project.org.
+To get a patch merged you must open a Merge Request against the kde/5.15 branch on the corresponding repository in https://invent.kde.org/qt/qt, describing the change as well as the reason it should be merged (e.g. by referencing a relevant defect report in an open source product). Also required is a reference to where it was approved upstream within https://codereview.qt-project.org.
+Note that this is gitlab (not gerrit), but without the usual permissions for KDE developers. So everyone must fork the repo first.
+Also note that the repo is synced with upstream qt (several times a day), so the commit you want to backport will be in there already, in dev or a 6.x branch, you can just cherry-pick it (with the option "-x"). Then push to your fork, and create a merge request for branch kde/5.15.
 === Who decides if a patch gets merged? ===
@@ Line 26: / Line 30: @@
 [https://invent.kde.org/qt/qt/qtbase Here] we have a version of Qt 5 that includes fixes for the issues we have found impacted the use of open source products. These patches can be obtained with the following command:
-     git format-patch origin/5.15 origin/kde/5.15
+     git format-patch v5.15.3-lts-lgpl..origin/kde/5.15
 === What is the license of the patches? ===
@@ Line 35: / Line 39: @@
 These patches can be obtained with the following command:
-     git format-patch origin/5.15 origin/kde/5.15
+     git format-patch v5.15.3-lts-lgpl..origin/kde/5.15
 They can then be integrated using the tooling specific to your distribution.
@@ Line 51: / Line 55: @@
 We expect the patch collection to be maintained for as long as is required to serve users of Qt 5.15-based Open Source products, but to be ultimately made obsolete by the adoption of Qt 6 when Qt 6 enables superior Open Source product development.
-=== I do not want to sign the Qt Contribution Agreement, can i still contribute patches? ===
+=== I do not want to sign the Qt Contribution Agreement, can I still contribute patches? ===
 As mentioned, we generally only accept patches if they have been merged upstream first. The only circumstance in which we may accept a patch not covered by the Qt Contribution Agreement is if it does not apply upstream for technical reasons.