Repository maintainer behavioral problems.

[GravisZro]

I've tried my best to help this project but I continue to run into the repeating behavioral problems of privileged group members. The primary issue is there is a tendency for such people to quickly dismiss problems they do not understand as not being problems.

I've warned about issues with merging and the discussion was immediately closed with the group member saying they didn't think it was a problem. I have also put forth a PR in order to enable a useful development feature in order to make deterministic builds but was promptly rebuffed and the PR closed because they did not understand it's purpose. This "I don't think it's a problem, you are dismissed"-style of response is exceptionally frustrating and only serves to promote strife.

From what I have observed, it appears that PRs by non-group users are often passed over for review in favor of PRs administrative users. This could be entirely subconscious but it would serve the community well to be mindful of outside PRs.

Those who hold power need to be worthy of it.

[bryanperris]

Hi @GravisZro,

I have been trying to be helpful to get your PRs reviewed and merged in, I do know that they been sitting idling for a long time. I am not sure what went on in the past, but everything now seems to be going much more smoothly here. We aren't admins here, we are simply software developers that have the permission to merge PRs into the main (maintainer access).

The whole point of github in general is that if you don't like the way a repository is running things, you can fork the repository, and do what you like there. There isn't anyone forcing you having to merge everything this repository's main branch. The point of creating these PR's is to help this project out but it also means going with the flow with the other developers here. We do appreciate the feedback too, remember its just feedback, we take it into consideration and then people vote on it if its a good idea or not. Every github project is different and the group of developers behind them will do things different from others.

[GravisZro]

I have been trying to be helpful to get your PRs reviewed and merged in

You have been exceptionally helpful in this regard. I have zero complaints about you.

We aren't admins here, we are simply software developers that have the permission to merge PRs into the main (maintainer access).

The term used is immaterial, the bottom line is there are capabilities that are reserved for a select few and they are not being used wisely.

it also means going with the flow with the other developers here.

I'm not asking for the world, I simply do not wish to be treated as if my time and efforts are immaterial. This is precisely what happened in #391.

[bryanperris]

When we look over PRs, yes we don't want to dismiss things so quickly, people took their time to make changes. Its just its never going to be perfect, like never 100%, some things will be accept and some not, no one can change that fate. Like with work projects, there are things I would want to change but there are the cases you can't, but you still have to do the job just so you get paid.

[winterheart]

Look, there nothing lost in #268 except my time that I spend to recheck your fork and main branch. You've created three issues in 5 minutes to get attention on matter that really not happen and all this hate speech is about your unability/unwilling properly read git merge log.

I'm remind you that is being polite is essential skill for open source developer. If you think that you loosing your time with this project, take a break and get some rest.

[GravisZro]

You've created three issues in 5 minutes to get attention on matter that really not happen and all this hate speech is about your unability/unwilling properly read git merge log.

1. You should absolutely not be throwing around the term "hate speech" so nonchalantly, it's a very real thing and this is not it. Using the term improperly degrades it's significance.

2. What happened to commit a77fdd74268a73c707aac940b087fc35c046b089? The git log has been altered.

   commit a77fdd74268a73c707aac940b087fc35c046b089
   Merge: 9c039e6 5e5e0c9
   Author: Louis Gombert <44813937+Lgt2x@users.noreply.github.com>
   Date:   Fri May 24 11:00:28 2024 +0000
   
   Merge pull request #268 from GravisZro/use/stdint
   
   Refactor to fixed width integer types: proven to be free of errors

I would also like to point out that you have just demonstrated the exact behavior I have pointed out in this very issue. You make unilateral decisions to simply dismiss the concerns of others without regard to them.

[winterheart]

2. It's absolutely normal and there no any issues regarding parsing git log. Merge commit means that two branches got merged into one, no more else. Tell me, why you saying that this commit loses your changes if is simple untrue?

Let's rewind some time back. You've created #391 and #392 that falsely accuses us that we lost part of your work and demands us to forcibly reset git main history which is guaranteed to lead troubles for all participants of this project. Just because you don't like default git merge policy (and everyone is ok with that) and trying breaching rules. And here you accuses some developer, that unwilling do what you want that eventually break repository, and others developers that spends their time to get things done with your contributions.

[GravisZro]

It's absolutely normal and there no any issues regarding parsing git log.

It may be normal when merging between branches but it's absolute abnormal for commits messages to evaporate. When rebasing every commit stays exactly where it occurred in history. I've not been in any profession environment that didn't use rebasing as a security measure. However, you seem to think you know better.

Your responses continue to be dismissive.