Message-ID: <Pine.LNX.4.64.0804110849520.28360@wrl-59.cs.helsinki.fi>
Date:	Fri, 11 Apr 2008 09:40:08 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Mark Lord <lkml@....ca>
cc:	David Miller <davem@...emloft.net>, jesper.juhl@...il.com,
	tilman@...p.cc, yoshfuji@...ux-ipv6.org,
	Jeff Garzik <jeff@...zik.org>, rjw@...k.pl,
	LKML <linux-kernel@...r.kernel.org>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: 2.6.25-rc8: FTP transfer errors

On Thu, 10 Apr 2008, Mark Lord wrote:

> David Miller wrote:
> > From: Mark Lord <lkml@....ca>
> > Date: Thu, 10 Apr 2008 20:27:14 -0400
> > 
> > > It's *your* bug -- you signed off on the commit.
> > 
> > I sign off on basically every networking commit, does that mean I have
> > to fix every networking bug and every networking bug is "mine"?
> ..
> 
> Absolutely, though to a varying degree.  That's the responsibility
> that goes with the role of a subsystem maintainer.  I once had
> such a role, and gave it up when I felt I could no longer keep up.  
> You still keep refering to it as "your (my) bug".
> It's not.  I had nothing to do with it, other than stumbling over it.

This bug is perfect example where bisect clearly was useful :-). Nobody 
knew whose bug it actually was until your bisect gave directions.

> When people stumble over a libata bug, I look hard to see if my code
> could possibly cause it.  Jeff looks even harder, because he's the
> current subsystem dude for libata.
>
> I never suggest a user search through a mountain of unrelated commits
> for something I've screwed up on.

But it is ok for you to ask an innocent net developer to do that (even 
with your terms as I hadn't signed off _anything_ related to that one),
hmm?

...You had this pretty demanding tone earlier:

> Or I can ignore it, like the net developers, since I have a workaround.
> And then we'll see what other apps are broken upon 2.6.25 final release.
>
> Really, folks.  Bug reports are intended to *help* the developers,
> not something to be thrown back in their faces.
>
> There do seem to have been a *lot* of changes around the tcp closing/close
> code (as I see from diff'ing 2.6.24 against latest -git).
>
> *Somebody* is responsible for those changes.
> That particular *somebody* ought to volunteer some help here,
> reducing the mountain of commits to a big handful or two.

...and also...

> > Anyways, here's five hours of free consulting for you

...Sure I could use similar words, but you might use the not-mine
bug approach again to deflect... :-( ...No, I don't mind really :-).
I well understand that I occassionally end up chasing things 
which are bugs that other people have caused, that's part of the
game.

> I give more directed help, patches to collect more relevant information, 
> and patches to try and resolve it.

Now that you have, as stated earlier, first looked the diffs (tcp*.c stuff 
mainly I suppose?!?), and the bisected it and found the breaker, and even 
patch is available already... Seriously, knowing all what's now available, 
how could we have solved _this particular case_ without that very useful 
help (bisect) from your side?

Yes, I went through the commit list (maybe you did as well), I'm not sure 
if Dave did as well. In addition, I checked a number of individual diffs 
too but this just isn't something very obvious (I have to admit though 
that I don't really understand all those namespace things, so I didn't 
even know how to look them too carefully).


-- 
 i.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists