Neon/QtUpdates: Difference between revisions

From KDE Community Wiki
 
(29 intermediate revisions by 4 users not shown)
Line 5: Line 5:
Testing phase is initial preparation stage of Qt updates, where new Qt version is prepared in the experimental repo, reasoning behind preparing it in experimental is sometime Qt updates can take days to prepare, preparing it in separate repo doesn't affect the production.
Testing phase is initial preparation stage of Qt updates, where new Qt version is prepared in the experimental repo, reasoning behind preparing it in experimental is sometime Qt updates can take days to prepare, preparing it in separate repo doesn't affect the production.


* For these Qt packages merge in order Neon/release into Neon/testing
* For these Qt packages merge in order Neon/release into Neon/testing (USE nci/qt_merge_and_bumper.rb; IF IT DOENS'T WORK FIX IT)
* For these the Qt packages merge in order latest tagged release from master into Neon/testing
* For these the Qt packages merge in order latest tagged release from master into Neon/testing
* If debian hasn't prepared the tag for the specific release, you would need to
* If debian hasn't prepared the tag for the specific release, you would need to
Line 29: Line 29:
Landing Qt is also two step process,
Landing Qt is also two step process,


== Building Qt in release/unstable/stable/release-lts ==
== Building Qt in release/unstable/stable ==


Generally speaking since this procedure freezes the unstable/stable and user editions for normal user, and important fixes and/or new developments can not be delivered to them in timely manner, it is recommended to do this process generally on Thu-Fri, and snapshot/un-divert next week on Monday/Tuesday.
Generally speaking since this procedure freezes the unstable/stable and user editions for normal user, and important fixes and/or new developments can not be delivered to them in timely manner, it is recommended to do this process generally on Thu-Fri, and snapshot/un-divert next week on Monday/Tuesday.


* Run both stable and unstable divert [https://build.neon.kde.org/view/mgmt/ mgmt jobs] to make developer builds go to /tmp/dev/unstable instead of /dev/unstable
* Run both stable and unstable divert [https://build.neon.kde.org/view/management%20%F0%9F%93%8B/ mgmt jobs] to make developer builds go to /tmp/dev/unstable instead of /dev/unstable.  Do this for both current and future releases if moving to a new LTS.
* Cherry-pick [https://github.com/pangea-project/pangea-tooling/commit/e609823b8fd312b9c4ce21cf367f6fa90ebc63c8 this commit] into pangea-tooling and let it deploy to move builds into /tmp archives.
* Change "repo_diversion" to true in nci.yaml and deploy with mgmt_tooling on both build.neon and xenon
* Notify other neon developers to NOT snapshot either Neon/release or Neon/release-lts.
* Notify other neon developers to NOT snapshot either Neon/release or Neon/release-lts.
* [https://packaging.neon.kde.org/qt/qtbase.git/tree/debian/README.source#n24 List of packages for qtdoc rebuilds]
* [https://invent.kde.org/neon/qt/qtbase/-/blob/Neon/release/debian/README.source#L19-37 List of packages for qtdoc rebuilds]
* For these packages:
* For these packages:
** Merge the Neon/testing branch to Neon/release.
** Merge the Neon/testing branch to Neon/release.
** Wait for builds to finish
** Wait for builds to finish
** Rebuild same packages again.
** Rebuild same packages again.
{{Input|1=<nowiki>
'jammy_[^_]+_[^_]+_(qtbase|qtdeclarative|qtlocation|qtsensors|qtwebsockets|qtwebchannel|qt5webkit|qttools)$'
</nowiki>}}
* Merge Neon/testing branch into Neon/release for other Qt packages, and wait for them to finish building.
* Merge Neon/testing branch into Neon/release for other Qt packages, and wait for them to finish building.
* Build stuff which deps on Qt-private-ABI in all editions.
* Build stuff which deps on Qt-private-ABI in all editions.
** akonadi
 
** kio-extras
{{Input|1=<nowiki>
** pyqt5
'jammy_[^_]+_[^_]+_(elisa|gammaray|peruse|qml-box2d|subtitlecomposer|verdigris|qtkeychain|akonadi|frameworkintegration|kdeconnect|kguiaddons|ki18n|kiconthemes|kirigami|kitinerary|krfb|kwayland|kwayland-integration|kwin|kxmlgui|layer-shell-qt|akonadi|kio-extras|pyqt5|python-qt4|kdeclarative|kwayland|kwayland-integration|plasma-framework|breeze|kwin|plasma-integration|skrooge|qqc2-desktop-style|gammaray|sddm)$'
** python-qt4
</nowiki>}}
** sip4
 
** kdeclarative
* And stuff that depends on that
** kwayland
 
** kwayland-integration
{{Input|1=<nowiki>
** plasma-framework
'jammy_[^_]+_[^_]+_(skrooge|fcitx-qt5|kmymoney)$'
** breeze
</nowiki>}}
** kwin
 
** plasma-integration
* Create a new kf5-qt content Snap and build it
** skrooge
 
** qqc2-desktop-style
* For Qt 6 the packages are something like..
{{Input|1=<nowiki>
./jenkins_retry.rb -b 'jammy_[^_]+_[^_]+_(kf6-frameworkintegration|kf6-kguiaddons|kf6-ki18n|kf6-kiconthemes|kf6-kirigami|kf6-kio|kf6-kirigami-addons|kf6-kwayland|kf6-kwindowsystem|kf6-qqc2-desktop-style|kwayland-integration|kwin|kf6-kxmlgui|layer-shell-qt|kio-extras|kf6-kdeclarative|kf6-plasma-framework|breeze|sddm|pyside6|kactivitymanagerd|kcolorpicker|kimageannotator)$'
</nowiki>}}


==  Making it available to users ==
==  Making it available to users ==
Line 62: Line 68:
Never land Qt after Wednesday unless it is absolutely required for some bug fixes or something. Landing Qt after Wednesday doesn't leave enough time for bug-fixes or stuff before weekend.
Never land Qt after Wednesday unless it is absolutely required for some bug fixes or something. Landing Qt after Wednesday doesn't leave enough time for bug-fixes or stuff before weekend.


* Stuff to test: kontact, fcitx-frontend-qt5, kmymoney, plasma, systemsettings, digikam
* Test both user edition with /release repo enabled, and dev unstable edition at least with archive link changed to /tmp/unstable instead of /unstable.
* Test both user edition with /release repo enabled, and dev unstable edition at least with archive link changed to /tmp/unstable instead of /unstable.
* Once at least 2 days of testing is done, snapshot user and user-lts
* Once at least 2 days of testing is done, snapshot user and user-lts
* Undivert the dev unstable and dev stable repos.
* Change "repo_diversion" to false in nci.yaml
* Make sure mgmt_tooling deployed on both neon and xenon
* Undivert the dev unstable and dev stable repos with the mgmt jobs


= Process improvements =
= Process improvements =

Latest revision as of 12:53, 22 February 2024

How to Update Qt in Neon

Testing phase

Testing phase is initial preparation stage of Qt updates, where new Qt version is prepared in the experimental repo, reasoning behind preparing it in experimental is sometime Qt updates can take days to prepare, preparing it in separate repo doesn't affect the production.

  • For these Qt packages merge in order Neon/release into Neon/testing (USE nci/qt_merge_and_bumper.rb; IF IT DOENS'T WORK FIX IT)
  • For these the Qt packages merge in order latest tagged release from master into Neon/testing
  • If debian hasn't prepared the tag for the specific release, you would need to
  • List of packages for qtdoc rebuilds
    • Drop the changelog delta with debian
    • Bump the Build-Depends and Build-Depends-Indep of the qt dependencies in debian/control to the Qt version being prepared
    • Add the changelog entry with the packaging version set to -0neon or +dfsg-0+neon, (i.e 5.12.1+dfsg-0+neon) it is used to avoid the merge conflicts with the debian merge.
    • git push all changes at once.
  • Let them build, and fix the remaining errors. Once the qtdoc related packages are rebuilt, you need to build them again in same order to make sure they are green.
  • After that follow procedure in previous step for rest of Qt packages
  • Once all Qt packages are done, build the other kde related packages in experimental view.

If builds are completed, you can test them on user edition by enabling /release and /experimental repositories, and upgrading your system. You would also have to pin the packages in experimental repo.

   Package: *
   Pin: release l=KDE neon - Experimental Edition
   Pin-Priority: 1001

If everything looks good, you can proceed to landing them in Neon/release

Landing Qt

Landing Qt is also two step process,

Building Qt in release/unstable/stable

Generally speaking since this procedure freezes the unstable/stable and user editions for normal user, and important fixes and/or new developments can not be delivered to them in timely manner, it is recommended to do this process generally on Thu-Fri, and snapshot/un-divert next week on Monday/Tuesday.

  • Run both stable and unstable divert mgmt jobs to make developer builds go to /tmp/dev/unstable instead of /dev/unstable. Do this for both current and future releases if moving to a new LTS.
  • Change "repo_diversion" to true in nci.yaml and deploy with mgmt_tooling on both build.neon and xenon
  • Notify other neon developers to NOT snapshot either Neon/release or Neon/release-lts.
  • List of packages for qtdoc rebuilds
  • For these packages:
    • Merge the Neon/testing branch to Neon/release.
    • Wait for builds to finish
    • Rebuild same packages again.
'jammy_[^_]+_[^_]+_(qtbase|qtdeclarative|qtlocation|qtsensors|qtwebsockets|qtwebchannel|qt5webkit|qttools)$'
  • Merge Neon/testing branch into Neon/release for other Qt packages, and wait for them to finish building.
  • Build stuff which deps on Qt-private-ABI in all editions.
'jammy_[^_]+_[^_]+_(elisa|gammaray|peruse|qml-box2d|subtitlecomposer|verdigris|qtkeychain|akonadi|frameworkintegration|kdeconnect|kguiaddons|ki18n|kiconthemes|kirigami|kitinerary|krfb|kwayland|kwayland-integration|kwin|kxmlgui|layer-shell-qt|akonadi|kio-extras|pyqt5|python-qt4|kdeclarative|kwayland|kwayland-integration|plasma-framework|breeze|kwin|plasma-integration|skrooge|qqc2-desktop-style|gammaray|sddm)$'
  • And stuff that depends on that
'jammy_[^_]+_[^_]+_(skrooge|fcitx-qt5|kmymoney)$'
  • Create a new kf5-qt content Snap and build it
  • For Qt 6 the packages are something like..
./jenkins_retry.rb -b 'jammy_[^_]+_[^_]+_(kf6-frameworkintegration|kf6-kguiaddons|kf6-ki18n|kf6-kiconthemes|kf6-kirigami|kf6-kio|kf6-kirigami-addons|kf6-kwayland|kf6-kwindowsystem|kf6-qqc2-desktop-style|kwayland-integration|kwin|kf6-kxmlgui|layer-shell-qt|kio-extras|kf6-kdeclarative|kf6-plasma-framework|breeze|sddm|pyside6|kactivitymanagerd|kcolorpicker|kimageannotator)$'

Making it available to users

Never land Qt after Wednesday unless it is absolutely required for some bug fixes or something. Landing Qt after Wednesday doesn't leave enough time for bug-fixes or stuff before weekend.

  • Stuff to test: kontact, fcitx-frontend-qt5, kmymoney, plasma, systemsettings, digikam
  • Test both user edition with /release repo enabled, and dev unstable edition at least with archive link changed to /tmp/unstable instead of /unstable.
  • Once at least 2 days of testing is done, snapshot user and user-lts
  • Change "repo_diversion" to false in nci.yaml
  • Make sure mgmt_tooling deployed on both neon and xenon
  • Undivert the dev unstable and dev stable repos with the mgmt jobs

Process improvements

  • Document release/lts wrt Qt.
  • FIXME openQA checks?
  • Build arm for experimental editions?