Qt5PatchCollection: Difference between revisions

From KDE Community Wiki
(Created page with "=== 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 o...")
 
Line 17: Line 17:
=== How do I get a patch merged? ===  
=== How do I get a patch merged? ===  


To get a patch merged you must open a Merge Request on 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 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.


=== Who decides if a patch gets merged? ===
=== Who decides if a patch gets merged? ===

Revision as of 08:59, 6 April 2021

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 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.

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 origin/5.15 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 origin/5.15 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.