Re: [Device-drivers-devel] [PATCH] ASoC: ad74111: new codec driver

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.