Supporting Qt 6 - What's needed?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Supporting Qt 6 - What's needed?
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.
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.
Re: Supporting Qt 6 - What's needed?
ACCIDENTAL DUPLICATE POST
Last edited by obelisk79 on Thu Jul 07, 2022 6:50 pm, edited 1 time in total.
Re: Supporting Qt 6 - What's needed?
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?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- adrianinsaval
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Supporting Qt 6 - What's needed?
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).Now you force these problems onto all other devs who are not directly involved with this migration. That is IMHO a really bad idea.
- adrianinsaval
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Supporting Qt 6 - What's needed?
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.Kunda1 wrote: ↑Thu Jul 07, 2022 6:45 pm 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?
Re: Supporting Qt 6 - What's needed?
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.
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.
Re: Supporting Qt 6 - What's needed?
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?
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?
Re: Supporting Qt 6 - What's needed?
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
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Supporting Qt 6 - What's needed?
there was thisStSt94 wrote: ↑Wed Jan 26, 2022 8:00 pm Please have a look at:
https://github.com/StStME/FreeCAD/tree/migrate/pyside6
Re: Supporting Qt 6 - What's needed?
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.