Request to test Qt6 migration
Hello, I am working on migration of BIT from Qt5 to Qt6 because the support for version 5 ends this year. It would help a lot if you could test this version for bugs related to the migration. Play around with BIT, try to open the windows and dialog. But don't do this on your productive machine. Use a test machine or virtual environment. Clone the specific branch from my BIT fork: $ git clone --branch qt6migration https://github.com/buhtz/backintime.git Follow the install instructions for developers and don't forget to install dependencies (e.g. PyQt6): <https://github.com/bit-team/backintime/blob/dev/CONTRIBUTING.md#build--insta...> In short: $ cd backintime/common $ ./configure $ make $ sudo make install $ cd ../qt $ ./configure $ make $ sudo make install There is an issue related to the migration: <https://github.com/bit-team/backintime/issues/1301> I would prefer reports directly to that ticket instead of the mailing list. By the way: If you know how feel free to contribute Qt related unit tests. Currently the GUI code is not covered by any tests. Thanks a lot. Christian
Do we need a GUI code freeze now for a smooth migration to Qt6 (and until when?)? I have still some open issues that would require small changes in the Qt5 GUI parts, eg. - add an "experimental" (better: fuzzy) snapshot log filter to find rsync errors that are currently not recognized as errors - add some missing tooltips - add hints for the rsync "--itemize" 11-characters output to make them better understandable to end users but I can postpone this of course until we have finished our migration to Qt6. On Fri, 2023-12-08 at 14:07 +0000, c.buhtz@posteo.jp wrote:
Hello,
I am working on migration of BIT from Qt5 to Qt6 because the support for version 5 ends this year.
It would help a lot if you could test this version for bugs related to the migration. Play around with BIT, try to open the windows and dialog. But don't do this on your productive machine. Use a test machine or virtual environment.
Clone the specific branch from my BIT fork:
$ git clone --branch qt6migration https://github.com/buhtz/backintime.git
Follow the install instructions for developers and don't forget to install dependencies (e.g. PyQt6): <https://github.com/bit-team/backintime/blob/dev/CONTRIBUTING.md#build--insta...> In short:
$ cd backintime/common $ ./configure $ make $ sudo make install
$ cd ../qt $ ./configure $ make $ sudo make install
There is an issue related to the migration: <https://github.com/bit-team/backintime/issues/1301>
I would prefer reports directly to that ticket instead of the mailing list.
By the way: If you know how feel free to contribute Qt related unit tests. Currently the GUI code is not covered by any tests.
Thanks a lot. Christian _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: python@altfeld-im.de
Hi Jürgen, Am 07.01.2024 12:38 schrieb BiT dev:
Do we need a GUI code freeze now for a smooth migration to Qt6 (and until when?)?
No code freeze needed. I (we) can do the testing in the separate branch. The behavior of Qt did not change. They just moved some classes into other namespaces. There is not much more of migration. Bugs that can appear are AttributeErrors because of unkown names and code that I might have missed to migrate. I can not imagine a real problem but there might be issues with packaging on the site of the linux maintainers. This can take some time. And I don't want to miss the next big distro releases. That is why I want to have the Qt6 version asap into the distros. About timeline: I would say do the migration after the next release. But when migrated to PyQt6 we IMHO should wait some months until the next release. If you have Issues that need to released asap or quit early then we should wait with the migration.
I have still some open issues that would require small changes in the Qt5 GUI parts, eg.
No problem. Decide on how urgent the issues are and when you want to release them. Qt6 migration can be done early or later when ever the other parts are ready. Kind Christian
On Sun, 2024-01-07 at 13:12 +0000, c.buhtz@posteo.jp wrote:
About timeline: I would say do the migration after the next release. But when migrated to PyQt6 we IMHO should wait some months until the next release. If you have Issues that need to released asap or quit early then we should wait with the migration.
Let's stick to our plan to prepare a release mid of January and apply time-boxing (what I can't fix won't be released), then we focus on the Qt6 version. Perhaps we can relax the idea of a pure Qt6 release a little bit since BiTs in CLI/backend are clearly separted from the GUI/App part so we could keep fixing these and release them together with the Qt6 release.
I have still some open issues that would require small changes in the Qt5 GUI parts, eg.
No problem. Decide on how urgent the issues are and when you want to release them. Qt6 migration can be done early or later when ever the other parts are ready.
OK. See my answer above above
participants (2)
-
BiT dev -
c.buhtz＠posteo.jp