kriegaex edited a comment 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 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:
* PR 355 is on branch
[`SUREFIRE-1881-fix`](https://github.com/kriegaex/maven-surefire/commits/SUREFIRE-1881-fix),
which does contain the fix from PR 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 PR 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 PR 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
