Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2

From: Jeff Garzik
Date: Tue Aug 07 2007 - 11:11:28 EST


James Bottomley wrote:
The initial bsg submit went via the block git tree ... which I believe
you have in -mm. We only started taking the updates via the scsi tree

Seven hours before you posted this, in <20070807001429.f8cb3b22.akpm@xxxxxxxxxxxxxxxxxxxx>, Andrew already noted it was not in -mm.

A trivial examination of the broken-out mm patches backs up the absence of Jens' block tree, too.

So let's put this myth / bad assumption to rest, shall we?


Yes ... particularly in large trees like SCSI, there's the maintainer
"bugger if I don't mail it out now I don't get it in for another three
months" factor.

That factor always exists. It's not confined to SCSI or large trees. It's basic the nature of the merge window. Nothing new or shocking here.


bsg had actually been sitting in the block tree since 2.6.21, so it had
followed the delayed merge rule ... it just seems that it didn't get
enough integration testing in that six months. This is what I consider

It didn't get integration testing, at least in part, because it did not hit our official pre-release tree. Quoth Andrew:
I pulled git-scsi-misc on July 19 and there was no bsg code in there at
all. I pulled again on July 20 and all the bsg code was in mainline.



I don't disagree; my point is that bsg did follow this rule (in fact it

Evidence says otherwise.


I wouldn't call bsg half baked ... it was very carefully matured. There
were just a few integration issues.

I wouldn't call bsg carefully matured, if in addition to not really gracing -mm with its presence, the userland API structure is still getting changes on July 29, 2007 (0c6a89ba640d28e1dcd7fd1a217d2cfb92ae4953).

Jeff


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