[alsa-devel] [Device-drivers-devel] [PATCH] ASoC: ad74111: new codec driver
Mark Brown
broonie at opensource.wolfsonmicro.com
Sun Mar 27 15:43:43 CEST 2011
On Sun, Mar 27, 2011 at 12:10:08AM -0400, Mike Frysinger wrote:
> On Sat, Mar 26, 2011 at 14:09, Mark Brown wrote:
> > It's a one line patch that totally changes the shape of the diff for
> > that hunk. As I said above this slows down review, it's jarring as one
> > has to stop and reverse engineer from the change if was intentional and
> > if it is sensible. It could be some unrelated cleanup, it could be (and
> > frequently is) context that got included in the diff by mistake.
> i still disagree, but considering you have the luxury of not accepting
> our patches, i guess it doesnt matter too much huh
It's not a luxury, believe me. Most of the issues you guys are having
here seem to be process issues as much as anything else, there's a
couple of things you could do which would really help make the whole
thing run more smoothly:
- Submit against current -next. It looks like you're mostly submitting
once a release or so, usually shortly after the release, with code
based off either the release that just went out or the release before
that. This means that you're going to be at least one kernel
revision out of date on current APIs and best practices and sometimes
means you're submitting code that won't even compile. ASoC moves
pretty quickly so you really do need to check with current code.
- Follow up promptly on reviews - I'm rarely seeing updates to patches
that involve any domain specific changes, and where there is followup
it's often at the next release. This interacts badly with the
submission against old code issues as that means you're likely to
require some fairly straightforward API updates but waiting to
resubmit means that you'll often end up requiring further updates
next time around.
For example, the SSM2604 driver you're submitting now was originally
sent last August and you sent patches for ADAV801/3, ADAU1361, ADAU1381
and ADAU1761 at the end of last year which mostly just needed fairly
straightforward updates for old kernel issues but which haven't been
resubmitted since. None of these devices look like they should be hard
to get support integrated into mainline but the above issues are making
that harder work than it needs to be.
More information about the Alsa-devel
mailing list