[ The person you are replying to was being sarcastic, BTW. ]
That's not the case we're talking about in this specific instance. In
this particular case the user is more than capable of bisecting, he
just isn't willing to invest the time.
And I'm supposed to be willing to invest the time to analyze the TCP
dumps or whatever to diagnose the problem? And I guess I should do
this for every single networking bug report or issue? Who is
going to clone me and the rest of the core networking developers
so that this is actually tenable?
That's ludicrious, I don't have a reproducer, this person does. And
if they bisect, we'll know _exactly_ what change introduced the
problem. Then I can use my brain to figure out the correct way
to resolve the problem.
Bisecting is a mindless activity that saves developers tons of time.
What people don't get is that this is a situation where the "end node
principle" applies. When you have limited resources (here:
developers) you don't push the bulk of the burdon upon them. Instead
you push things out to the resource you have a lot of, the end nodes
(here: users), so that the situation actually scales.
--
