wsteffe wrote: ↑
Wed Mar 27, 2019 11:22 am
Jee-Bee wrote: ↑
Wed Mar 27, 2019 11:03 am
because most users that replay here are users who are on this forum for some time...
or are developers who understand the risk of implementing such major changes
I may not see how this separation is supposed to mitigate the risk.
The realthunder work was tested by few users/developers in a configuration (fork) which includes both topological naming and LinkStage3.
The maturity is therefore assessed for that united code. In my opinion it is more probable that the separation will create new problems than fix them.
You see "an assembly system" and "a toponaming fix". But if you look at the code, you will see changes all around FreeCAD, which are needed for his implementation.
Divide and conquer may not always be the best solution, but it generally helps.
I have been looking only to the Sketcher parts of realthunder with the aim of integrating them. That is peanuts with the bulk of his work and still it is a huge load of changes.
Changes need to be peer reviewed to maintain a minimum level of quality and cohesion. Peer reviewing has an average effectiveness of around 50% in detecting bugs before integration.
There is this computer science paper indicating that people cannot think simultaneously on something involving more than 9 items at the same time, most people not being even able to manage 5. This is why creating individual commits for each feature, or even for each aspect of a feature that touches a different workbench or part of FreeCAD is important, creating separate on topic PRs help manage complexity and reduce risks during integration.
For example, there is the risk that in some parts, FreeCAD has evolved and arrived to diverging solutions in a module. Realthunder has rebased his branch several times, but last time I looked, there were unrebased parts. This is an integration and regression risk.
In any case, when Werner looks at it, he will say what he requires.