And again:
uwestoehr wrote: ↑Wed Oct 13, 2021 11:15 am
abdullah wrote: ↑Wed Oct 13, 2021 10:41 am
Sorry, but I disagree. You requested to make a PR because of your personal wish.
I want everybody to test a fully functional feature. This is not achievable with a PR.
There was a meeting to share different points of view etc. Meetings are there to check if the own way can be improved. I try to communicate to avoid misunderstandings. So maybe I misunderstood the others then in the meeting. Let's discuss this the next meeting please and I hope you can join this.
Personal opinion: Concerning it is not achievable with a PR, I disagree. The PR provides exactly this - a fully featured master plus the new feature. That is ideal for testing the feature, see below.
And my duplicate bug report is a nice case how a PR would have been a benefit:
EDIT: This issue is a good example why a PR would be a benefit - I can take my file, start master, see the issue is there, so the PR is independent of this.
The cool thing with the PRs that one does not need to know the code, but can just focus on playing around with the feature and always cross-check with master.
You are arguing in circles:
- This has nothing to do with the meeting. You have agreed that it is the common understanding that I can directly merge to the branch. This does not need yet another meeting for clarification.
- You disagree that I cannot get a large audience via PR. Your argument is self-defeating.
- You exemplify you reporting a bug in unrelated code as how a PR would have been a benefit. If it were a PR you would also have reported the same. It is simply immaterial to be in a PR or in master for you to report a bug.
- You appear to claim that you cannot compile a previous commit of the master branch and test, or use the master from the previous day.
uwestoehr wrote: ↑Wed Oct 13, 2021 11:15 am
abdullah wrote: ↑Wed Oct 13, 2021 10:41 am
I already know the opinions and ideas of those who can compile the code by themselves, as this started some weeks ago. As I told you I want global feedback. Not local feedback. I know I cannot get global feedback until the feature is merged into master.
This argumentation does only work for developers with merging rights. All other developers have to make PRs and need people who can compile to give feedback.
For example chrisB is a great help of getting feedback but he cannot compile. So he needs a master build.
So as it works for all devels without merging rights, there is a PR, people who can compile give feedback, the code can be optimized if necessary, then it is merged. We provide frequently master builds and then get feedback of the full audience.
No. Read again the minutes of your meeting. It does not work for all developers with merging rights. It does not apply to new Integrators, who do have merging rights. It only applies to more experienced core developers.
I find problems following the logic behind your statements: You acknowledge that ChrisB would be great to have as tester and for feedback (which I can only agree). You acknowledge that he would only be fully enabled when he gets a master build. Yet you want me to undergo a PR which will only delay his feedback. This, I should do, because developers without merging rights need to go that path (for good other reasons). But I want his feedback. Sometimes it appears that your feedback is more valuable than his. No offense here. If I had to choose a single tester for sketcher features, it is highly likely that I would choose ChrisB (he is not the only very capable power user, he is certainly a very capable one). Thankfully, I can get several other power users who are brilliant and are in the same situation as ChrisB. And, by merging it to master, I can also get your feedback and the one from other developers. I am not preventing you from giving your feedback. I am certainly not prioritizing your feedback over theirs. Do not ask me that. I won't comply.
There is yet another reference to the need for "optimizing" code. If for any chance, at any moment, you have problems with my code, come forward. I do not shy away from my mistakes. I may learn yet another way how not to do something.
uwestoehr wrote: ↑Wed Oct 13, 2021 11:15 am
abdullah wrote: ↑Wed Oct 13, 2021 10:41 am
There is nobody I look up more to here than Werner. He is well over my function here. He has merged tons of UI functionality without asking (and for good reason). He has the same right as anybody else to create a PR have it reviewed. The reasons behind his decision are known to him.
I worked with him for some Part and PartDesign features and he started to make PRs, exactly for the reason that others can test and give feedback.
This is now my personal opinion: I don't think it is good that certain decisions are only known to one person. I contributed for example the first year mostly to TechDraw and could ask wandererfan. Now he is no longer available and unless there are proper code comments, it is sometimes not clear why some things are made they way they are.
I get the feeling that you feel personally offended because I want you to consider to change your workflow when it comes to UI. That is sad, since I appreciate you very much, like your work and use it with joy. So let's please put aside the personal level.
However, the environment around us changes. That's why I wrote about my experiences wit the change from SVN -> Git. I know myself how I can sometimes react on something that changes my workflow. So I hope you take some days to consider if making here an there a PR than directly merging could suit you and the community. And of course not for every simple case a PR is necessary
I cannot emphasise the following enough: You know UIs better than I do and I welcome you improving UIs (I do have issues when it appears that your decisions do not take into account other classes of users. We have an open issue with one dialog size, which I have not forgotten. It is waiting for decisions that I want made with global feedback, thus the merging.). I treat all users the same.
What I totally fail to understand, is why you cannot make a PR for a UI change after the functionality is merged. Which dark force may prevent you from doing so. May my UI be so abhorrent that you cannot bear with it until your PR is merged?
Let's work out those circular references again:
- Werner started doing PRs for UI things when working with you. I am ok with that. I do not know the background. It could be that the PR was mostly about UI and that functionality needed to be adapted to the UI, so it made more sense to get the right UI first. If Werner did it, it was the right choice. This has however nothing to do with the following lines.
- It is not good that certain decisions are known to only one person. I fully agree. Please ask. It is not that I am ignoring you. I am always open to explain my decisions. Nobody prevents you from looking at my code and asking. You are not going to do anything else if I do a PR. You are going to read the code. If the code prompts questions, you will make them. If it does not you won't. It is not as if I were concealing the code from you. I try to comment every non-obvious decision in the code. If something is not clear, do come forward. If I died tomorrow, it would not matter that I did many PRs in the past.
- It is not really about changing the workflow. It is about whether it is meaningful. Here we do have a big disagreement. When I evaluate your reasons why you want to change it, they are not sound enough to outweigh the reasons why I want to follow it. More precisely, I cannot make logic out of them.
- I do not consider mine an overreaction. But a necessary reaction so settle a source of dissonance. I always consider the community before myself when taking my actions in this forum and the repository. I still think that my actions follow this consideration in full.
uwestoehr wrote: ↑Wed Oct 13, 2021 11:15 am
abdullah wrote: ↑Wed Oct 13, 2021 10:41 am
I feel no urge to compete.
I don't understand this statement. I wrote it that you know something about me, just to know each other. I find such info useful because for example knowing the background of a person helps to understand each other better. A natural scientist (I studied physics) acts different than e.g. a linguist. A professional coder works different than a hobbyist etc. So knowing each other does never harm and I am surprised that I when make a neutral description about me you write about competition.
I have a different opinion based on my own experience.
I do not like to be biased when I make my decisions. I should treat you (and any other) the same regardless of whether you are a physicist or an engineer. Whether you dedicate to software development professionally or you design structures. Whether you are a lawyer or an English teacher at school.
I purposefully omit my background, because similarly, I do not want others to be biased by what I am or I am not. If I am wrong, I am wrong. If I am right, I am right. I believe in the power of words, not in the power of the speaker. I can easily change my mind with compelling arguments. It is unlikely I will change it in the absence of arguments.
I matter what the people say. Their ideas. What they want to achieve. When it comes to this community, I enjoy enabling people to achieve their goals. I am not a professional coder, but I do like to code a lot. I am always striving to improve my skills. The FreeCAD community is for me, what for others is watching a football game at the local pub, only that with coding instead of football and worldwide written social interaction instead of chatting.