Ronciak, John wrote:
What was tested was the entire patch set which included the pre-fetch
patch. Since there so much controversy over the pre-fetch patch let
last time we moved that patch to the end of the patch set. Then we
asked ourselves if we should send that patch out at all. We decided not
to stir things up and leave that last patch (pre-fetch) out. This is
what broke the patch set. So to make it less controversial we used the
patch except we removed the actual pre-fetch calls from the patch and is
now what has applied.
We do test the patch sets before they go out but this time because of
what has been happening we really needed to get them accepted so we
pulled that one out. This was a mistake on our part but we were trying
to do what was best all the way around. We should have also tested
without that last patch applied which we didn't do. We would have
obviously caught this if we did.
This didn't prove anything, we just wanted to explain what happened. We
are sorry for the thrash. We are working on other policies and
procedures to help stop things like this from happening in the future.
The ideal situation would be to send out patches as soon as they are
created by the engineer. Maintain them publicly somewhere (preferably
netdev-2.6.git#e1000). This gives developers ample time to review your
work, and exposes the code to the largest Q/A lab in the world (the
Internet). If patches need to be revised or even deleted from the
queue, that's easy enough. Once changes are "cooked" sufficiently, we
can push them upstream.
Infrequent code drops just don't work, and we all waste valuable time
rediffing and chasing kernel versions.
I'm having this problem with the wireless side of Intel as well.
Sourceforge download pages get updated with new driver versions, with
the Linux kernel actually seeing associated patch submissions weeks,
sometimes months later. Each code drop is a huge set of patches, and
things come to a grinding halt while the dust settles, reconciling
upstream changes with out-of-tree vendor changes.
Its just plain inefficient. We already have processes in place, in
Linux, to Q/A new code, and merge it into the codebase at a [moderately]
sane pace. I would love it if Intel would embrace these processes,
rather than inventing your own. We all want the same things... keeping
the driver stable, supporting new hardware, improving performance where
possible.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html