[alsa-devel] [PATCH] keywest: Convert to new-style i2c driver

[Paul Mackerras]

Jean Delvare writes:

> > I sympathize, but throwing disruptive changes into Linus' tree when
> > we're past -rc3 is not the way to solve the problem.
> 
> We're past -rc3 because people discuss instead of testing my patches.
> Otherwise everything would be merged already.

Well, no.  The first conversion patch that I saw was posted after the
merge window had already closed, on 8 April.

> And really, these changes (sound drivers) don't qualify as disruptive.
> You might argue about the thermal management driver changes if you
> want. But sound drivers, nothing bad will happen if they accidentally
> break.

That's what we call a "regression". :)

> But linux-next will only build-test the code. That I have already done,
> so it really doesn't buy my anything. Developers (including me) don't
> look at warnings in linux-next, and I don't think linux-next gets a lot
> of testing.

If you remove the legacy interfaces then even a build test will point
out the drivers that still need to be converted. :)

> Also, I can't push all untested patches to linux-next. In particular
> the 4 patches that touch thermal management on powermac, need to be
> tested successfully by at least one person before I can push them. You
> did test the therm_pm72 patch, and I thank you for that, so that one is
> in linux-next, but the other 3 ones need testing.
> 
> So, really, you're trying to solve the wrong problem. Whether the
> patches go to Linus now or in the next merge window, doesn't really
> matter.

It does matter, actually.

> And 2.6.31 isn't the kernel to remove an interface which was scheduled
> for removal in 2.6.29 and then 2.6.30 and which is blocking the
> development of features people need badly.

What's so special about 2.6.30 that it matters whether the legacy
interfaces are still there or not?

As for blocking development, you can remove the legacy interfaces
today in your next branch and get on with development immediately.  So
the "blocking development" argument has zero relevance to what goes
into Linus' tree for 2.6.30.  Even if you got the legacy interfaces
removed for 2.6.30 you still wouldn't be able to get any new features
based on that into 2.6.30.

And this is a particularly bad time to be hastily trying to get
powermac driver changes upstream, since Ben H. is on vacation.

> So, once again, can powermac developers/users please test my patches?

Can we compromise on this?  I'll do everything I reasonably can to
help you get the powermac driver patches tested and working before the
2.6.31 merge window, if you agree to leave the drivers and interfaces
in Linus' tree as they are for 2.6.30.

Paul.