kriegaex commented on pull request #354: URL: https://github.com/apache/maven-surefire/pull/354#issuecomment-875207616
@Tibor17, why are you continuing the conversation from #355 here in #354? Isn't this whole issue chaotic enough? Two Jira issues, 3 PRs? Why can we not at least leave continue a started conversation where it belongs? But OK, I am answering here, following you: > I am not part of the problem. You are part of the problem We both are, which is why I called you **a part** of it and not the whole problem. Each communication problem has two sides. Maybe the way I explain it too verbose for you and you are, like you said, lazy or unwilling to read long descriptions. Maybe your English is simply not good enough to understand what I am saying, and I am trying not to hold it against you. But if you ignore what I wrote or misunderstand repeatedly, the only way left for me to make you understand is to use more words, more screenshots, more logs, always hoping that maybe with more information you would understand. But as smart as you are, Tibor, you are also quite stubborn, not believing users what they say, despite evidence. You also seem to be stressed out with a high work load, which also I do not hold against you, but the effect is that it makes you sloppy, first not reading thoroughly, then not understanding correctly, then complaining about me because I try to explain in more detail in order to make yo u understand what you could have understood long ago if you just would have read thoroughly. > you wrote two Jira issues at least and did not clarify simple problem Oh, now it is a simple problem, after at first you only fixed half of it and closed the issue prematurely, and then the second one took you months to investigate the root cause, several iterations and feedback from two people to fix it, while in the meantime a few times you claimed to know how to or to have fixed it already. What is simple about that? This issue was neither simple nor easy to fix. In hindsight, now that you know what was wrong, it is easy to say for you it was simple. But it took you a long time to find out what the heck was wrong. I provided you with two simple test cases to reproduce it, what is not OK about that? It is not my job to analyse your code, it is yours. Users raise issues, maintainers solve them. So far, so normal. Sometimes, if you are lucky, a user can solve a problem himself, if he knows enough about the code base and understands enough about the problem to create a PR (like the small one #355). But #354 was not that trivial. I wanted the problem to be solved, so I did what was in my power to contribute to a solution, i.e. I commented, re-tested and finally created a new PR in order to save you some time, because again you closed an issue without really checking the result: * The build log proved that the new IT I contributed was not running due to the naming glitch. * You never analysed tested what would happen when running the same IT in a situation which would make the JVM hang, i.e. the situation fixed in #354. This is called a regression and always possible. So I tested that for you by backporting the IT to the commit before the bugfix in order to provide a test case for you to find out why the zombie processes ocurred. > I told you one year ago that many other contributors make an experiment and many contributors make a deep analysis but you did not. That is incorrect. Since the very beginning I explained to you how to reproduce the problem. You had everything you needed to analyse this problem. I explained in detail all the symptoms of the problem in prose, with logs, screenshots. First, you did not believe that there even was a Surefire problem to begin with, arguing for weeks that using a Java agent was the problem. You were wrong, I was right. I also analysed correctly that it was about the JVM logging something before the `SurefireForkNodeFactory` fork node implementation context was fully initialised, and again I had a hard time convincing you. In the end, I was right again. I could not have solved the problem myself, because I do not know the code base and am out of my league here, but my description was correct and my educated guesses about what might be wrong were correct too. You simply ignored or misunderstood them repeatedly. You have the expertise in Surefire, so you were the one who finally solved the problem, an d I am immeasuribly grateful for that. But I am certainly not the reason that this took so long. You simply kept ignoring my hints. > Why the other contributors can make perfect analysis and they help us but you actually explain simple issue and known issue complicated. Actually, most Jira issues for Surefire contain no analysis at all, they simply describe a problem in too little detail without even explaining how to reproduce it. This is bad, which is why many issues sit there and rot, ignored by the Surefire team, for years. I did not want that to happen to my issues, which is why I was active, describing whatever new facts I learned about the problems while experimenting myself or re-testing your intermediate commits. This is what a good user does: to try and be part of the solution. But again: My role in this was mostly a user's, not a contributor's. Users raise and describe issues, maintainers analyse and solve them. Why are you implicitly blaming me for not knowing as much about your code base as you? > you did the thing which nobody would do and that means nobody would fire a new PR based on old source code You keep saying that, even though I explained to you and over again that the PR was **not** based on old source code. For the 5th time or so: * #355 is on branch [SUREFIRE-1881-fix](https://github.com/kriegaex/maven-surefire/commits/SUREFIRE-1881-fix), which does contain the fix from #354. * Branch [before-SUREFIRE-1881](https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881) is **not** the PR, but a back-port of the IT to the state before the #354 merge, because that is the simplest way to find out what would happen in the future in case the JVM hangs again due to a yet undetected edge case or a regression. But what did you do? Instead of merging #355, you recreated my commits under your own name and closed the issue. Of course we can open a new PR or new Jira issue for the zombie process problem, but before doing so I first wanted your feedback and see if this is something to be solved within SUREFIRE-1881 or you preferred to have a new issue for it. Same goes for the . Instead every other contributor would open a ticket and not a PR because the troubles can be discussed in Jira and PR comes afterwards when all is clarified. > The #355 solves 4 things (timeout for zombie processes, refactoring, modified IT by adding a test for m-surefire-p, unstable test `forcedShutdownVerifyingLogs`). No, it does not! It simply renames the test to `*IT` in one tiny commit and then adds another test case in another, separate commit - exactly the same that you also did in your two commits on master. The other two I did not touch at all, simply mention them in order to bring them to your attention, because I noticed them while working on that PR. I even said: >> Why in one case on MacOS `JUnit47ParallelIT.forcedShutdownVerifyingLogs` failed, I do not know, but I think I have seen it before. It looks like this test is flaky and should be fixed **(in another PR).** > So, no developer would open one PR with first commit solving `4` different issues I did not! That you repeat saying that, does not make it true. > because real developers know how big chaos it may produce Yes, which is why I did **not** do it that way! Mentioning or discussing a problem is not a commit. --- > You are not a technical person, you are an officer > Real developer does not do this but the officers who pretend they are developer Seriously? This is how you are playing this? To try and disqualify me because I once mentioned that I am an agile coach and no longer a professional developer, only doing programming for fun? But I am coaching developers, teaching them how to do their jobs, also technically, not just in an organisational way. Dear Tibor, I think you should adopt a friendlier, more humble and less condescending attitude. It would also be helpful if you would learn to read messages more thoroughly, because that would save everyone a lot of time and effort for further writing and reading, trying to clarify the misunderstandings cause by your sloppy reading. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org