Andrew Morton wrote:
On Fri, 28 Sep 2007 23:29:44 -0400 Jeff Garzik <jeff@xxxxxxxxxx> wrote:
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in merging, part of which is my own fault, and I
can only promise to try and do better there. Part of which is a result
of stuff being dependent on -mm (which requires plenty of time
hand-merging) rather than libata-dev.git#upstream.
2) I have been intentionally staging major libata behavior changes
between Linux releases. Luckily most of these are behind us, but, in
several cases with things like ACPI on/off (hopefully 'on' in 2.6.24),
probing changes (switchover to new EH for probing via hotplug, etc.),
interrupt handling changes.
I dislike getting "too much" into a single release, because of the
difficulty of getting large scale feedback without a major kernel release.
So far I think the kernel releases have been pretty darn successful in
"not breaking everybody" but that clearly conflicts with desired
development speed, given the glacial pace of each kernel release. If
each kernel release were 1-2 months apart, we would have many more
testing points, and I think you guys and I would both be happy. But
that's not the reality today, with 3+ month kernel release cycles (ugh!!).
I'm very much interested in hearing suggestions and comments.
There's an easy fix...
The releases are slow because a) there's so much stuff in them and b) it
takes so long to stabilise it all.
If all developers were to be more careful in their work, and take more time
to review and test others' work, both problems get fixed: less code, higher
quality.
We don't know how to make this happen. We haven't even tried.
I think you missed part of my point, with regards to libata:
Even though stuff gets tested in -mm and in mainline -rc releases, we
simply do not have the test audience that a major kernel release does,
when it comes to determining whether new libata probe behavior will
break millions of boxes (or not).
Unlike CPUs and other hardware, our attached devices (disks, cd-roms)
are entirely black boxes of [mis]behavior, with plenty of libata
behavior based _entirely_ on observations in the field, not stuff
documented in a specification somewhere.
3-4 true "trial and error" periods per year (kernel releases) give
libata a similar number of test points per years. Not a whole lot of
room when you consider that we must actively (but carefully!)
experimental with new kernel features in the each kernel release.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
