Merging of my Link branch

[abdullah]

Werner must be on holidays as he is abnormally silent.

This won't be merged until he comes back. As far as I know, he is basically the only one who can review and decide on a merge for this kind of "big amount of c++ work" (unless somebody manages to get jriegel back ).

[Jee-Bee]

(unless somebody manages to get jriegel back ).

I think @jriegel is lost in the big amount of new code too...

[abdullah]

(unless somebody manages to get jriegel back ).

I think @jriegel is lost in the big amount of new code too...

For the skills I have seen in his code, I do not think it would take him much time to "come back", should he decide to... but if you were trying to tease him, I can go along: "Sure he couldn't do it, not even if he wanted to"

[triplus]

Yeah. I agree.

[looo]

Don't know if it is possible to split the hole branch up in 3 or 4 steps. so not everything change in one moment...

I also recommend to split the branch. I guess there is more motivation to review a smaller amount of diff...

[realthunder]

Don't know if it is possible to split the hole branch up in 3 or 4 steps. so not everything change in one moment...

I also recommend to split the branch. I guess there is more motivation to review a smaller amount of diff...

That's going to be difficult. Although there are a few small features that can be easily split up, the main 'Link' feature requires a lot of changes. I originally splitted this into three set of patches. But with the first two big patch set, there is nothing to show for in FC. Only after the third one will there be the actual 'Link' command in toolbar. And it is still not very useful, for example, it can't be used in Part, Editing won't work. There are numerous bug fixes following my original Stage3 patches.

The way I see it, we can just try my branch with existing workbenches, and confirm that nothing is broken. If so, then it is a bug, and I'll fix it. If this can pass, I think it is an indication that the merge will at low risk. The new stuff can be broadly divided by two category, 'Link' and topo naming. 'Link' stuff is best tested with my Assembly3 WB. Topo naming is tested by a few cases in post, and I am sure there is someone willing to come up with more elaborated test cases.

ping

Hi wmayer, what do you think? Are you back yet?

[realthunder]

ping

Pinging wmayer again. Don't know how to ping before. Shame on me.

[triplus]

Well the truth is you haven't updated the existent one or opened a new pull request just yet:

https://github.com/FreeCAD/FreeCAD/pull/876

Therefore i guess that should be the next step.

[Kunda1]

Is https://github.com/FreeCAD/FreeCAD/pull/876 obsolete ?

[realthunder]

Is https://github.com/FreeCAD/FreeCAD/pull/876 obsolete ?

Yes, it is obsolete. This PR is based on my branch LinkStage1, and my current LinkStage3 is a descendant of this. But there are so many bug fixes after this, it is very difficult to split it again, and not to mention error prone.

Well the truth is you haven't updated the existent one or opened a new pull request just yet:

https://github.com/FreeCAD/FreeCAD/pull/876

Therefore i guess that should be the next step.

That PR has 2.5K line changes, and can be considered a big one. The current change set is about 50K. I doubt github's PR facility is suitable for handling this, which is why I wrote documents and started this thread.

ping

Hi wmayer, still waiting for your response here.