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.