On Fri, Jul 15, 2005 at 02:47:46PM -0700, Mark Gross wrote:
> This problem is the developer making driver changes without have the
> resources
> to test the changes on a enough of the hardware effected by his change, and
> therefore probubly shouldn't be making changes they cannot realisticaly test.
Such is life. The situation arises quite often where fixing a bug
for one person breaks it for another. The lack of hardware to test on
isn't the fault of the person making the change, nor the person requesting
the change. The problem is that the person it breaks for doesn't test
testing kernels, so the problem is only found out about when its too late.
The agpgart driver for example supports around 50-60 different chipsets.
I don't have a tenth of the hardware that it supports at my disposal,
yet when I get patches fixing some problem for someone, or adding support
for yet another variant, I'm not going to go out and find the variants
I don't have. By your metric I shouldn't apply that change.
That's not how things work.
> What would be wrong in expecting the folks making the driver changes have
> some
> story on how they are validating there changes don't break existing working
> hardware?
It's impractical given the plethora of hardware combinations out there.
> I could probly be accomplished in open source with subsystem
> testing volenteers.
People tend not to test things marked 'test kernels' or 'rc kernels'.
They prefer to shout loudly when the final release happens, and
blame it on 'the new kernel development model sucking'.
> > The only way to cover as many combinations of hardware
> > out there is by releasing test kernels. (Updates-testing
> > repository for Fedora users, or -rc kernels in Linus' case).
> > If users won't/don't test those 'test' releases, we're
> > going to regress when the final release happens, there's
> > no two ways about it.
>
> You can't blame the users! Don't fall into that trap. Its not productive.
You're missing my point. The bits are out there for people to
test with. We can't help people who won't help themselves,
and they shouldn't be at all surprised to find things breaking
if they choose to not take part in testing.
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
