All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] sound: max98090: Remove executable bit
@ 2013-03-19 21:58 Joe Perches
  2013-03-20  9:57 ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2013-03-19 21:58 UTC (permalink / raw)
  To: Liam Girdwood, Mark Brown
  Cc: Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-19 21:58 [PATCH] sound: max98090: Remove executable bit Joe Perches
@ 2013-03-20  9:57 ` Mark Brown
  2013-03-20 15:22   ` Joe Perches
  0 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2013-03-20  9:57 UTC (permalink / raw)
  To: Joe Perches; +Cc: Takashi Iwai, linux-kernel, alsa-devel, Liam Girdwood


[-- Attachment #1.1: Type: text/plain, Size: 294 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-20  9:57 ` Mark Brown
@ 2013-03-20 15:22   ` Joe Perches
  2013-03-20 16:36     ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2013-03-20 15:22 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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.




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-20 15:22   ` Joe Perches
@ 2013-03-20 16:36     ` Mark Brown
  2013-03-20 22:54       ` Joe Perches
  0 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2013-03-20 16:36 UTC (permalink / raw)
  To: Joe Perches; +Cc: Takashi Iwai, linux-kernel, alsa-devel, Liam Girdwood


[-- Attachment #1.1: Type: text/plain, Size: 974 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-20 16:36     ` Mark Brown
@ 2013-03-20 22:54       ` Joe Perches
  2013-03-21 16:25         ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2013-03-20 22:54 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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/



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-20 22:54       ` Joe Perches
@ 2013-03-21 16:25         ` Mark Brown
  2013-03-21 17:16           ` Joe Perches
  0 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2013-03-21 16:25 UTC (permalink / raw)
  To: Joe Perches; +Cc: Takashi Iwai, linux-kernel, alsa-devel, Liam Girdwood


[-- Attachment #1.1: Type: text/plain, Size: 2499 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 16:25         ` Mark Brown
@ 2013-03-21 17:16           ` Joe Perches
  2013-03-21 17:44               ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2013-03-21 17:16 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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+"$@"}
:
$



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 17:16           ` Joe Perches
@ 2013-03-21 17:44               ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2013-03-21 17:44 UTC (permalink / raw)
  To: Joe Perches
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
@ 2013-03-21 17:44               ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2013-03-21 17:44 UTC (permalink / raw)
  To: Joe Perches; +Cc: Takashi Iwai, linux-kernel, alsa-devel, Liam Girdwood


[-- Attachment #1.1: Type: text/plain, Size: 806 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 17:44               ` Mark Brown
  (?)
@ 2013-03-21 17:53               ` Joe Perches
  2013-03-21 18:44                   ` Mark Brown
  -1 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2013-03-21 17:53 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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...


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 17:53               ` Joe Perches
@ 2013-03-21 18:44                   ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2013-03-21 18:44 UTC (permalink / raw)
  To: Joe Perches
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

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...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
@ 2013-03-21 18:44                   ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2013-03-21 18:44 UTC (permalink / raw)
  To: Joe Perches; +Cc: Takashi Iwai, linux-kernel, alsa-devel, Liam Girdwood


[-- Attachment #1.1: Type: text/plain, Size: 1120 bytes --]

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...

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 18:44                   ` Mark Brown
@ 2013-03-21 19:16                     ` Joe Perches
  -1 siblings, 0 replies; 17+ messages in thread
From: Joe Perches @ 2013-03-21 19:16 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
@ 2013-03-21 19:16                     ` Joe Perches
  0 siblings, 0 replies; 17+ messages in thread
From: Joe Perches @ 2013-03-21 19:16 UTC (permalink / raw)
  To: Mark Brown; +Cc: Takashi Iwai, linux-kernel, alsa-devel, Liam Girdwood

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 19:16                     ` Joe Perches
  (?)
@ 2013-03-21 20:37                     ` Mark Brown
  2013-03-21 20:40                       ` Joe Perches
  -1 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2013-03-21 20:37 UTC (permalink / raw)
  To: Joe Perches
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 20:37                     ` Mark Brown
@ 2013-03-21 20:40                       ` Joe Perches
  2013-03-21 21:26                         ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Joe Perches @ 2013-03-21 20:40 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

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.

> people
> who submit many patches ought to be examples of how to work smoothly.

I'm done with this conversation.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] sound: max98090: Remove executable bit
  2013-03-21 20:40                       ` Joe Perches
@ 2013-03-21 21:26                         ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2013-03-21 21:26 UTC (permalink / raw)
  To: Joe Perches
  Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2013-03-21 21:26 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-19 21:58 [PATCH] sound: max98090: Remove executable bit Joe Perches
2013-03-20  9:57 ` Mark Brown
2013-03-20 15:22   ` Joe Perches
2013-03-20 16:36     ` Mark Brown
2013-03-20 22:54       ` Joe Perches
2013-03-21 16:25         ` Mark Brown
2013-03-21 17:16           ` Joe Perches
2013-03-21 17:44             ` Mark Brown
2013-03-21 17:44               ` Mark Brown
2013-03-21 17:53               ` Joe Perches
2013-03-21 18:44                 ` Mark Brown
2013-03-21 18:44                   ` Mark Brown
2013-03-21 19:16                   ` Joe Perches
2013-03-21 19:16                     ` Joe Perches
2013-03-21 20:37                     ` Mark Brown
2013-03-21 20:40                       ` Joe Perches
2013-03-21 21:26                         ` Mark Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.