Realthunders work

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Realthunders work

Post by yorik »

chrisb wrote: Wed Nov 25, 2020 9:54 pm It is not sufficient that it works and no errors were found by the users. It must be maintainable for years to come.
Exactly. FreeCAD is before anything else a social project. It's people who make FreeCAD. Betting everything on one single person and having that person solely responsible for fixing large parts of FreeCAD would be a foolish operation, no matter how skilled that person is. We must always maintain FreeCAD maintainable, accessible, sustainable, healthy.

It takes much time? Yes. We all agree. But merging everything from RT now is not a solution. We would transfer almost 100% of the bug fixing to him, not to mention other areas such as documentation. Half the developers would be thrown out of the FreeCAD code because it would just change too much too fast, and how many would stop working on the project? We must all learn to work together. IMHO that's more important than the technical side, and that's what keeps FreeCAD strong. FreeCAD would be nothing without all the people who have worked on it for years, that's even written on the console message :)

RT's work is magnificent, don't get me wrong. We all want it merged up to the last bit. But being careless just because we want the yummy new features would definitely not be a good thing to do. RT provides custom builds almost every week, users are not "blocked", there is no reason not to do it the right way.

Now if someone has STRATEGIES in mind of how we can speed up the process, please fire away ;)
tonilupi
Posts: 16
Joined: Fri May 08, 2020 11:14 pm

Re: Realthunders work

Post by tonilupi »

yorik wrote: Thu Nov 26, 2020 10:35 am Now if someone has STRATEGIES in mind of how we can speed up the process, please fire away ;)
Well, I use Freecad for the design of parts that I print in 3d and I've been using the RT version since early versions.

What I like the most is the robustness against the topological naming problem, I'm not able to break any design even forcing the bug with this branch.

Sometimes I think it's going too fast and it doesn't give me time to assimilate so many advances ;)

The situation is that we have two lines (Master and RT) that are getting further and further away and the longer it takes to join them the bigger the work to be done.

Now we have that version 0.19 is still formally "in development" when I think it is perfectly usable in production and used by a lot of people instead the "old" 0.18.

My proposal is to change the situation of the 0.19 to official and then to merge RT with Master and create a really alpha version that can only be tested by those who are really interested and continue to test and debug the "official" 0.19.
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Realthunders work

Post by Zolko »

yorik wrote: Thu Nov 26, 2020 10:35 am Now if someone has STRATEGIES in mind of how we can speed up the process, please fire away ;)
This is not very honest, as it has been said over and over again since nearly a year:

tonilupi wrote: Thu Nov 26, 2020 1:36 pm Now we have that version 0.19 is still formally "in development" when I think it is perfectly usable in production and used by a lot of people instead the "old" 0.18. My proposal is to change the situation of the 0.19 to official and then ...
The STRATEGY is simple: name v0.19 as the new stable version, and start merging realthunder's branch into v0.20-dev, beginning with the topological naming. It is still not clear WHY it has not happened, especially as the AddonManager is broken in the official stable branch, and all users with problems are ALWAYS told to use the 0.19 "development" branch.

Please don't try to blur the line, the question is not about STRATEGY but about those who decide to not follow it through. NOTHING will happen before v0.19 is out, and if realthunder's work drifts further away from the "official" FreeCAD it's not his "fault" but that of the FreeCAD maintainers who refuse to do the only sane thing that there is to do. And this without even an explanation despite many efforts and questions by lots of people.
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Realthunders work

Post by yorik »

Zolko wrote: Thu Nov 26, 2020 1:52 pmThis is not very honest, as it has been said over and over again since nearly a year:
I know that, but the "forget about all the community mechanisms we've been trying to build for years and merge everything now" doesn't seem a good idea, I explained above why. I also know that for many people (including me) 0.19 is perfectly usable, but there are still several big bugs and regressions, all core devs will agree.

There are many things that can be done to help, instead of complaining, and me and several others have also said that over again since nearly a year.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Realthunders work

Post by chrisb »

Zolko wrote: Thu Nov 26, 2020 1:52 pm NOTHING will happen before v0.19 is out, and if realthunder's work drifts further away from the "official" FreeCAD it's not his "fault" but that of the FreeCAD maintainers who refuse to do the only sane thing that there is to do.
Please refrain from such biased speech which insinuates that those who merge pull requests are doing basically nothing or even worse, that they stubbornly don't look on some pull requests.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
watsug
Posts: 100
Joined: Sat Sep 26, 2020 10:51 pm

Re: Realthunders work

Post by watsug »

yorik wrote: Thu Nov 26, 2020 10:35 am Now if someone has STRATEGIES in mind of how we can speed up the process, please fire away
I'm not a software developer, so this approach might be completely wrong for source management, so can only speak as an user.

Would it be possible to have a second "experimental" branch of official FreeCAD that future big changes can be developed in? This would invite more people to try out, test and contribute to the code?

For unknowing users, it could feel better to download an official "experimental" version of FreeCAD, than a "random persons" personal branch (as people are aware of FreeCAD but might not be aware who realthunder is).
paullee
Veteran
Posts: 5097
Joined: Wed May 04, 2016 3:58 pm

Re: Realthunders work

Post by paullee »

watsug wrote: Thu Nov 26, 2020 3:23 pm Would it be possible to have a second "experimental" branch of official FreeCAD that future big changes can be developed in? This would invite more people to try out, test and contribute to the code?
It sounds logical to me :D

It would had been much easier for me to download Realthunder's version one or two years ago - I just had downloaded his AppImage version recently :lol:
aapo
Posts: 615
Joined: Mon Oct 29, 2018 6:41 pm

Re: Realthunders work

Post by aapo »

Zolko wrote: Thu Nov 26, 2020 1:52 pm The STRATEGY is simple: name v0.19 as the new stable version, and start merging realthunder's branch into v0.20-dev, beginning with the topological naming. It is still not clear WHY it has not happened, especially as the AddonManager is broken in the official stable branch, and all users with problems are ALWAYS told to use the 0.19 "development" branch.
I think you are correct in all the other ways, but conveniently forget one thing: The .FCStd file format. I believe that the core devs think that as soon as v0.19 is branded as "stable", the .FCStd file format will be set in stone, and it needs to be supported for the foreseeable future. And unfortunately, the exact file format is not specified in some external documentation, but it depends on what properties particular v0.19 dev versions happen to write there. As long as the v0.19 versions are "dev", it can be said that the files are not "official" .FCStd files, and they need not be supported. So, my personal belief is that the delays in publishing the v0.19 are linked to making sure that the .FCStd files are sane and as future-proof as possible. And, that is only possible by making the v0.19 executable to write as sane and well-structured .FCstd files as possible.

I agree that the situation is quite unfortunate; on one hand the official FC clearly lags behind, and on the other hand I don't have much faith on the future-proofness of realthunder's Linkstage branch file format, as good as the branch currently is in other regards.
User avatar
obelisk79
Veteran
Posts: 1061
Joined: Thu Sep 24, 2020 9:01 pm

Re: Realthunders work

Post by obelisk79 »

As a relative newcomer to FreeCAD I quickly shifted to the realthunder builds. That said. It's a complicated issue, and I agree with yorik. Perhaps once 0.19 is finalized the suggestion of beginning the massive task of integration of large portions of realthunder's work could begin. But there are limited resources (unpaid developers, time, etc) and long term maintainability and structure are also very important. Realthunder does integrate main branch changes into his branch with a decent frequency and things are very usable as-is. Keep up the good work to those who are actively involved in development.

I would add (I also realize that there has been previous discussions on this matter) that I think the creation of a foundation similar to how blender has done, would be of great benefit to FreeCAD in order to provide greater structure and a mechanism to allow for collection of donation money, lobby for industry/business investment which could afford the opportunity to have a handful of paid core programmers. But that is a separate issue.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Realthunders work

Post by abdullah »

Zolko wrote: Thu Nov 26, 2020 1:52 pm
yorik wrote: Thu Nov 26, 2020 10:35 am Now if someone has STRATEGIES in mind of how we can speed up the process, please fire away ;)
This is not very honest, as it has been said over and over again since nearly a year:

tonilupi wrote: Thu Nov 26, 2020 1:36 pm Now we have that version 0.19 is still formally "in development" when I think it is perfectly usable in production and used by a lot of people instead the "old" 0.18. My proposal is to change the situation of the 0.19 to official and then ...
The STRATEGY is simple: name v0.19 as the new stable version, and start merging realthunder's branch into v0.20-dev, beginning with the topological naming. It is still not clear WHY it has not happened, especially as the AddonManager is broken in the official stable branch, and all users with problems are ALWAYS told to use the 0.19 "development" branch.

Please don't try to blur the line, the question is not about STRATEGY but about those who decide to not follow it through. NOTHING will happen before v0.19 is out, and if realthunder's work drifts further away from the "official" FreeCAD it's not his "fault" but that of the FreeCAD maintainers who refuse to do the only sane thing that there is to do. And this without even an explanation despite many efforts and questions by lots of people.
I beg to differ.

The problem is complex. Nobody is to blame and this should not become a blame game. There is a positive attitude by all the actors involved. I can understand the voice as an user. I can only give you the view of the developer and PR reviewer (in practice) in the hope that you can better understand where I stand.

Realthunder is very capable and probably has a lot of free time. He produces functionality at a high rate. The functionality he produces is very nice and pleasing for users. The c++ code he produces is generally correct, although sometimes there is a clash of coding style with other developers, such as the extensive use of macros and sometimes over-refactoring which leads to developers losing track of their own code. This are important things in a community project, but they are minor things where I am sure an agreement can be reached, but as everything requires time and effort.

The major issue here is that the PRs that he produces are huge and very difficult to review. The complexity of the review process increases exponentially with the size of the PR. For example, it took me 7 days to review one of his PRs with my time availability. I have 1-2 hours per day of time availability. And no, the problem is not reviewer time availability per se. We may be just fine with the one we have if we optimise the PRs to minimise review time.

The main driving factor in the example above is the mixture of different functionalities in a single PR, together with major refactorings. Many of this PRs extend over the core and different workbenches. This further decreases the chance of the reviewer detecting important problems, such as unnecessary couplings between components. Things that if let go, will result in huge future problems. The problem with code are not the small bugs, that can be solved over time (with credit were it is due, he is not prone to produce this kind of bugs, and I would even say I am proner to produce them than he is). The big problem, if you would allow a bad simile as I am not an architecture guy, it is like building a two stories house without (proper) foundation and beams. You may get away with it, it may look beautifully finished and even the house of your dreams, but the chances that it will all eventually fall on your head and smash it are pretty high (if you hold that it is impossible to build a two stories house without foundation and beams, I will not contest it, but you get the idea of what I mean). This is not to say he is producing awful architecture, please understand the exaggeration in the simile. But some architectural decisions arise from time to time that are not what we are aiming for. I would be a hypocrite if I would claim that I never produced solutions having architectural issues and, in fact, I have had PRs rejected, where the functionality was nice, but the code did not meet the standard (to my mind defining status for sketcher geometry comes to mind). Today, when architectural issues may arise in my code, I have my own PRs checked by Werner, even if I am authorised to merge directly into master. My point is rather, that my PRs potentially having structural issues are not massive, do not expand several functionalities and certainly do not include major refactorings inside. This makes them way easier for a reviewer to review within a reasonable time frame. I think everybody will win if Realthunder's PRs were directed to a single feature and without major refactors inside. It is fine to produce double or even triple the amount of such simpler PRs. I personally would welcome that decisions taken are reflected in the commit messages. Here I will come with another example. Imagine I come to your work table with blueprints for a space shuttle and ask you to review them. Just the blueprints, no calculations, no studies of alternatives, no reasoning why a given solution was chosen, or which considerations were taken in the decision-making process. Again it is an exaggeration, but I guess you can get the idea. Such presentation is not aimed at facilitating a review process. Similarly, one can produce a PR with the aim to minimize the time taken by the review process and one can produce a PR with other aims. The former takes more preparation time in a kind of tasks that many developers do not enjoy. The former is almost guaranteed to be reviewed in a short period. The latter may not. It is not that such PRs aimed at mergeability do not exist. I have seen such commits (even recently). I have merged commits for bug fixes where the developer fully explained the problem, where it originated, under which circumstances and why he thinks the solution he provides is good. I could almost have merged it by only looking at the PR message, because from reading it I was almost sure the code could not be wrong (I always read the code though). That kind of PR is just art and the developer has my deepest gratitude as reviewer. I feel he is facilitating my work and that makes me feel good (who does not want to have work colleagues who facilitate one's work). Never forget this other consideration: Review time is a gift by other developers. Certainly Werner's review time is priceless. Think that developers reviewing PRs put on hold their own development and dedicate a part of their coding time for the sake of the project.

I will finished as I started. Nobody is to be blamed. I welcome realthunder's positive attitude as he is giving away his own work in the form of PRs. Overall I think he does a huge amount of work by maintaining his fork as a single man branch. He certainly has my admiration for that. He has bright ideas too, but anybody seen his work knows that.

This kind of "rant posts" I think they are necessary in order to create awareness of the unrest. Let me translate them into what I see: 1) there is an inefficiency, 2) there is space for improvement, 3) we should seek a more efficient development strategy. However, no solution will come from the effort of a single side. As a community driven project, this can only be realised through respect for all involved and teamwork.

And give you a live insight: Tomorrow I will put my current development work on hold to review another huge PR...and I know it may take again a week before I can continue my development...

Sorry if this came as a disappointment. It was not my intention.
Post Reply