Supporting Qt 6 - What's needed?

[doia]

Is see the advantage of merging the QT6 migration branch back into master, when and ONLY when the migration is (nearly) finished and does not yield any major problems.

I can think of a myriad of reasons not to merge intermediate commits of a major framework migration into master. There will probably be only a few devs who will work on this migration. During this process there will inevitably be build breaking errors. Even minor commits could break the build, as the committing dev can not be aware of all possible hickups in all used system/setups etc. Not intentionally of course, but that's how it works. Now you force these problems onto all other devs who are not directly involved with this migration. That is IMHO a really bad idea.

[obelisk79]

ACCIDENTAL DUPLICATE POST

[Kunda1]

This is beside the point, but how do we coordinate this with Toponaming? Do we work on it concurrently or prioritize one over the other?

[adrianinsaval]

Now you force these problems onto all other devs who are not directly involved with this migration. That is IMHO a really bad idea.

Nobody is planning on merging untested code onto master, you make a PR, it is tested in all platforms, reviewed, iterated, repeat until done and then it's merged. I agree if there will be several devs involved a branch should be created once we have an initial PR (no point in doing it now if it's just going to be the same as master).

[adrianinsaval]

This is beside the point, but how do we coordinate this with Toponaming? Do we work on it concurrently or prioritize one over the other?

I say toponaming is waaaay more important than this, it would be best to have that in first to not get huge conflicts but if there's no guarantee or estimate for merging that and someone can't realistically help with toponaming but can help with migration it might be better if they do it anyways, we can't freeze freecad's development for a mystical merge that never comes.

[obelisk79]

If migrating to Qt6 perhaps a discussion about migrating to QML could be had? I think that would be a significantly larger task though, but grouping such work together might make sense from a logical standpoint.

Oh, and I wholeheartedly agree that TNP mitigation is substantially more important. But different devs have different areas of interest/focus so other proposed efforts shouldn't necessarily be discounted either. I just wish I had more talent with development.

[chennes]

Toponaming is independent of this: no Qt related code should be anywhere near the toponaming code. We should not have any issues with merge conflicts, etc.

I think this discussion is basically moot until there is actually a Qt6 PR to consider -- then we can look at how much code we are talking about, and how many PRs we expect it to be. So I circle back to my original question: is there any code in the works? Does anyone have a Qt6 branch we can start looking at?

[chennes]

I can think of a myriad of reasons not to merge intermediate commits of a major framework migration into master.

We will not merge intermediate commits -- only functionally complete PRs will be considered.

I remind everyone that git is decentralized by design: you are always welcome to create a branch in your fork and to invite other collaborators to either submit PRs to YOU, or to join a team you give access to that repository. In many respects that is easier than trying to use an "official" branch, since you'd still have to submit PRs to the official branch and wait for them to be reviewed, etc.

[adrianinsaval]

Please have a look at:

https://github.com/StStME/FreeCAD/tree/migrate/pyside6

there was this

[chennes]

there was this

At a quick glance we probably don't want to base any further work on those experiments, since that's a wholesale replacement of Qt5 with Qt6. What we will ultimately merge needs to support using either, via a switch in cMake.