[alsa-devel] [PATCH] sound: max98090: Remove executable bit

[Mark Brown]

On Thu, Mar 21, 2013 at 12:16:45PM -0700, Joe Perches wrote:

> The commit isn't in -next so I have no idea what
> you actually applied. (nor do I really care btw)

The fact that you don't care is kind of the problem here, aside from
the extra effort involved the active resistance to change isn't good
especially given that you are keen on things like get_maintainers and
so on.

> Did you try it?

> It commits:

> ASoC: sound: max98080: Remove executable bit

Which clearly neither makes sense (think about what that means...) nor
is consistent with other commits to either the driver or the subsystem.

> If you're really anal about it and you want
> sound: for sound/soc removed,

Yes, of course.

> perl -p -i -e 's/^(?:ASoC:\s*)?(?:sound:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' ${1+"$@"}

So that'll work for this particular error but then will fail if someone
mistakenly uses any other prefix and won't do anything about the driver
specific prefix.  

In any case this is not useful as even if you concoct something that
fixes every possible error it still doesn't help with the incoming patch
queue since searches don't match, the rewrite would need to be done on
incoming mail and that's not a good idea.

> This is a "your taste" issue only, and do keep in mind
> mountains vs molehills.

The reason I'm complaining here is that you routinely send very trivial
patches which don't apply cleanly - sometimes they don't apply at all
since you send them against inappropriate trees as well as requiring
hand editing.  This isn't a good pattern, it should be changed - people
who submit many patches ought to be examples of how to work smoothly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20130321/5db5d010/attachment-0001.sig>