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.