[alsa-devel] [PATCH] sound: max98090: Remove executable bit
Source files shouldn't have the executable bit set.
Signed-off-by: Joe Perches joe@perches.com --- include/sound/max98090.h | 0 sound/soc/codecs/max98090.c | 0 sound/soc/codecs/max98090.h | 0 3 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/include/sound/max98090.h b/include/sound/max98090.h old mode 100755 new mode 100644 diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c old mode 100755 new mode 100644 diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h old mode 100755 new mode 100644
On Tue, Mar 19, 2013 at 02:58:43PM -0700, Joe Perches wrote:
Source files shouldn't have the executable bit set.
I've applied this but I'm fed up to the back teeth of having to hand edit trivial patches from you because you ignore the subject line styles of subsystems and make up your own.
On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote:
On Tue, Mar 19, 2013 at 02:58:43PM -0700, Joe Perches wrote:
Source files shouldn't have the executable bit set.
I've applied this but I'm fed up to the back teeth of having to hand edit trivial patches from you because you ignore the subject line styles of subsystems and make up your own.
Your style rules just don't matter to me and you can ignore the patches and fix it yourself.
Or better, create a tool for others to use that follow your silly style rules.
On Wed, Mar 20, 2013 at 08:22:16AM -0700, Joe Perches wrote:
On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote:
I've applied this but I'm fed up to the back teeth of having to hand edit trivial patches from you because you ignore the subject line styles of subsystems and make up your own.
Your style rules just don't matter to me and you can ignore the patches and fix it yourself.
Or better, create a tool for others to use that follow your silly style rules.
This is just like any other coding style thing - you should be creating patches that look like other patches for the affected, if there's things like obvious visual differences in what you're doing you're doing it wrong.
Automation doesn't work for things like this, there's a good solid reason why there's generally a human involved in patch; the other people who submit lots of cleanups generally manage to figure this out usefully, you might want to discuss techniques with them.
On Wed, 2013-03-20 at 17:36 +0100, Mark Brown wrote:
On Wed, Mar 20, 2013 at 08:22:16AM -0700, Joe Perches wrote:
On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote:
I've applied this but I'm fed up to the back teeth of having to hand edit trivial patches from you because you ignore the subject line styles of subsystems and make up your own.
Your style rules just don't matter to me and you can ignore the patches and fix it yourself.
Or better, create a tool for others to use that follow your silly style rules.
This is just like any other coding style thing - you should be creating patches that look like other patches for the affected, if there's things like obvious visual differences in what you're doing you're doing it wrong.
We've had this conversation before and I proposed to you a simple solution. https://lkml.org/lkml/2010/11/16/245 and I still more or less agree with Florian https://lkml.org/lkml/2010/11/16/314
I'm not doing it wrong. You have another demand others don't. I simply don't find it necessary to cater to you.
If you want it to be agreed that there is a specific form for subject headers that varies by maintainer tree, change SubmittingPatches Paragraph 11.
Automation doesn't work for things like this, there's a good solid reason why there's generally a human involved in patch; the other people who submit lots of cleanups generally manage to figure this out usefully, you might want to discuss techniques with them.
I suggest you use a git pre-commit hook to your tree and use sed/perl to add a specific prefix if it doesn't exist. http://codeinthehole.com/writing/tips-for-using-a-git-pre-commit-hook/
On Wed, Mar 20, 2013 at 03:54:32PM -0700, Joe Perches wrote:
On Wed, 2013-03-20 at 17:36 +0100, Mark Brown wrote:
This is just like any other coding style thing - you should be creating patches that look like other patches for the affected, if there's things like obvious visual differences in what you're doing you're doing it wrong.
We've had this conversation before and I proposed to you a simple solution. https://lkml.org/lkml/2010/11/16/245
If you want a script feel free to write one, as repeatedly discussed (including in that thread) it's not completely trivial. Personally I don't feel it's a useful use of time and it's certainly not something I'd have any intention of using.
and I still more or less agree with Florian https://lkml.org/lkml/2010/11/16/314
What he's saying there is that maintainers should just hand edit the patches; that's just stupid especially for trivial patches where all that should be needed is a git am run. You're doing this a lot, you should be getting it right. First time and occasional submitters tend to get a lot more leeway but when submitters send a lot of patches but continually ignore feedback...
I'm not doing it wrong. You have another demand others don't. I simply don't find it necessary to cater to you.
...or even actively reject it then it shouldn't be a surprise when the strength of the pushback ends up increasing.
If you want it to be agreed that there is a specific form for subject headers that varies by maintainer tree, change SubmittingPatches Paragraph 11.
This is all pretty basic stuff (and if it were going to be spelled out in more detail it'd be along with all the other stuff about writing good subject lines). Like I say it's also most important to frequent submitters and not something it's essential to get right first time.
Automation doesn't work for things like this, there's a good solid reason why there's generally a human involved in patch; the other people who submit lots of cleanups generally manage to figure this out usefully, you might want to discuss techniques with them.
I suggest you use a git pre-commit hook to your tree and use sed/perl to add a specific prefix if it doesn't exist. http://codeinthehole.com/writing/tips-for-using-a-git-pre-commit-hook/
I don't think you're quite understanding the issues with automation here. Or indeed the desired end result.
On Thu, 2013-03-21 at 17:25 +0100, Mark Brown wrote:
I suggest you use a git pre-commit hook to your tree and use sed/perl to add a specific prefix if it doesn't exist. http://codeinthehole.com/writing/tips-for-using-a-git-pre-commit-hook/
I don't think you're quite understanding the issues with automation here. Or indeed the desired end result.
What issue is that?
Maybe this would work for you...
$ cat .git/hooks/applypatch-msg #!/bin/sh
. git-sh-setup
perl -p -i -e 's/^(?:ASoC:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' {$1+"$@"}
test -x "$GIT_DIR/hooks/commit-msg" && exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} : $
On Thu, Mar 21, 2013 at 10:16:15AM -0700, Joe Perches wrote:
On Thu, 2013-03-21 at 17:25 +0100, Mark Brown wrote:
I don't think you're quite understanding the issues with automation here. Or indeed the desired end result.
What issue is that?
That one needs a bit more taste and thought to work out what's appropraite than can be guaranteed easily with a script, things like working out drive level prefixes for example.
Maybe this would work for you...
$ cat .git/hooks/applypatch-msg #!/bin/sh
. git-sh-setup
perl -p -i -e 's/^(?:ASoC:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' {$1+"$@"}
test -x "$GIT_DIR/hooks/commit-msg" && exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} : $
No, that's going to leave essentially every commit that needs fixing up still needing manual fixup.
On Thu, 2013-03-21 at 18:44 +0100, Mark Brown wrote:
On Thu, Mar 21, 2013 at 10:16:15AM -0700, Joe Perches wrote:
On Thu, 2013-03-21 at 17:25 +0100, Mark Brown wrote:
I don't think you're quite understanding the issues with automation here. Or indeed the desired end result.
What issue is that?
That one needs a bit more taste and thought to work out what's appropraite than can be guaranteed easily with a script, things like working out drive level prefixes for example.
[perfectly useful git applypatch-msg hook script removed]
No, that's going to leave essentially every commit that needs fixing up still needing manual fixup.
Then I'm sure that's your job as a maintainer to modify whatever patches you get to suit your taste.
I think what I did is perfectly tasty.
ttfn, o+o, ttyl, tafn, etc...
On Thu, Mar 21, 2013 at 10:53:13AM -0700, Joe Perches wrote:
On Thu, 2013-03-21 at 18:44 +0100, Mark Brown wrote:
That one needs a bit more taste and thought to work out what's appropraite than can be guaranteed easily with a script, things like working out drive level prefixes for example.
[perfectly useful git applypatch-msg hook script removed]
No, it really isn't. Have you tried looking at the output? It's not going to do the right thing for the subject line here for example, never mind any other cases.
No, that's going to leave essentially every commit that needs fixing up still needing manual fixup.
Then I'm sure that's your job as a maintainer to modify whatever patches you get to suit your taste.
One of the things I'd really expect that a frequent submitter of trivial patches would be doing is to make an effort to improve the quality of what is being sent. If it's at the point where you're sending a lot of patches and it's more effort to apply them than to review them there's a problem.
This is something that generally causes no problems for submitters...
On Thu, 2013-03-21 at 19:44 +0100, Mark Brown wrote:
On Thu, Mar 21, 2013 at 10:53:13AM -0700, Joe Perches wrote:
On Thu, 2013-03-21 at 18:44 +0100, Mark Brown wrote:
That one needs a bit more taste and thought to work out what's appropraite than can be guaranteed easily with a script, things like working out drive level prefixes for example.
[perfectly useful git applypatch-msg hook script removed]
No, it really isn't. Have you tried looking at the output? It's not going to do the right thing for the subject line here for example, never mind any other cases.
Define "the right thing" for this instance.
The commit isn't in -next so I have no idea what you actually applied. (nor do I really care btw)
Did you try it?
It commits:
ASoC: sound: max98080: Remove executable bit
If you're really anal about it and you want sound: for sound/soc removed,
perl -p -i -e 's/^(?:ASoC:\s*)?(?:sound:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' ${1+"$@"}
This is a "your taste" issue only, and do keep in mind mountains vs molehills.
cheers, Joe
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.
On Thu, Mar 21, 2013 at 01:40:22PM -0700, Joe Perches wrote:
On Thu, 2013-03-21 at 21:37 +0100, Mark Brown wrote:
you routinely send very trivial patches which don't apply cleanly
That's demonstrably false.
It's sadly not, at least for the things I get to see - as far as I have been able to tell you submit against either Linus' tree or the last release (I think the former) rather than the relevant development trees or even -next which means that if anyone else has looked at the same area of code there will be conflicts.
I'm done with this conversation.
Oh, well. Hopefully you'll take on board the feedback.
participants (2)
-
Joe Perches -
Mark Brown