linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ljkenny@gmail.com (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too
Date: Thu, 2 Aug 2012 08:45:18 +0100	[thread overview]
Message-ID: <20120802074517.GA19231@gmail.com> (raw)
In-Reply-To: <20120801194134.GA4103@sirena.org.uk>

On Wed, Aug 01, 2012 at 08:41:34PM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2012 at 05:08:24PM +0100, Mark Brown wrote:
> > On Wed, Aug 01, 2012 at 02:50:32PM +0100, Lee Jones wrote:
> 
> > > >It's very disappointing to see such an error exist, and even more
> > > >disappointing that there's no interest in fixing the driver.
> 
> > > This is incorrect. I'm sure the driver will be fixed post-haste when
> > > Ola returns back from vacation. If I can find some time I might
> > > dabble in the mean-time also.
> 
> > It may not be what you're intending but it's unfortuantely what's I'm
> > seeing.
> 
> Just to expand on this a bit since I've found myself pushing back in
> this sort of way far too often with these recent serieses and it's
> making everyone grumpy:
> 
> What I'm seeing here is a lot of patches getting sent with problems that
> I'd really not expect from someone sending such a high volume of
> patches.  Things like the lack of documentation for the DT bindings for
> example, it's something that's mandatory and which people doing lots of
> device tree work really ought to be aware of.  There's also noticable
> pushback with fixing some of these issues, and like I say this happens
> often enough to be really noticeable.
> 
> This isn't awesome from a review point of view, it's not nice to find
> issues in things and when it happens a lot for the wrong sort of thing
> it ends up seeming like the time spent doing the reviews isn't valued.

Okay, seeing as we're lying our cards on the table, here's my hand:

I'm in a very difficult position here. My initial task was to enable
Device Tree on all drivers associated with the Snowball low-cost 
development board. I was working very closely with Arnd, who was regularly
requesting code restructuring, both within the drivers and in platform
code. Something I was only too pleased to do. Then some of the original
authors noticed the restructuring and I subsequently spent a great deal of
time defending my actions. Now we have some systems in place to keep
everyone informed and happy.

Over time, the requests for Maintainers have Snowballed (pun intended). My 
task now seems to be enabling drivers for Device Tree _and_ fix all 
associated driver bugs, including any requested restructuring and API
adoption. What you fail to notice is that I am only one person, and hopping
all over the code-base trying to do everyone's bidding is no mean feat. In
reality I am no more obliged to fix driver bugs than you are. In fact as
the Maintainer of some of these subsystems, perhaps you could even help out
a bit?

With regards to the documentation, I am perfectly aware that any new binding
needs to be documented. Leaving it out was intentional until we can agree on
the bindings. After you told me you review the documentation rather than
the code bindings themselves ( pffft... ;) ) I added the documentation to
the patch-set. I always had every intention of writing them!

On your last point about feeling undervalued, that's not the case at all. I
do respect your opinion and value your reviews. They are always completed
quickly and are very thorough. If I had one complaint it's that you are
_too_ stringent. Some of this stuff really doesn't matter.

We are all trying to do good things here. Please try not to be too over-
critical. We all know Mainlining is a good thing. Perhaps less people
would be so frightened of it, thus more people would do it if the reviews
weren't such a ball-ache ( for want of a better expression :) ).

  reply	other threads:[~2012-08-02  7:45 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-31 13:31 [PATCH 1/6] Bugfixes and clean-ups bound for the v3.6 RCs Lee Jones
2012-07-31 13:31 ` [PATCH 1/6] ASoC: ab8500: Inform SoC Core that we have our own I/O arrangements Lee Jones
2012-07-31 13:31 ` [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too Lee Jones
2012-07-31 13:42   ` Mark Brown
2012-07-31 14:25     ` Lee Jones
2012-07-31 14:28       ` Mark Brown
2012-07-31 14:38         ` Lee Jones
2012-07-31 14:54           ` Mark Brown
2012-07-31 15:15             ` Lee Jones
2012-07-31 15:18               ` Mark Brown
2012-08-01  7:19                 ` Lee Jones
2012-08-01 13:20                   ` Mark Brown
2012-08-01 13:50                     ` Lee Jones
2012-08-01 16:08                       ` Mark Brown
2012-08-01 19:41                         ` [alsa-devel] " Mark Brown
2012-08-02  7:45                           ` Lee Jones [this message]
2012-08-02 17:56                             ` Mark Brown
2012-08-03  8:30                               ` Lee Jones
2012-08-04  0:48                                 ` Mark Brown
2012-08-02  5:58                     ` Ola Lilja
2012-08-02  9:59                       ` Mark Brown
2012-08-10 11:43                       ` Linus Walleij
2012-08-02 12:21   ` Lee Jones
2012-07-31 13:31 ` [PATCH 2/6] ARM: ux500: Remove unused snowball_of_platform_devs struct Lee Jones
2012-07-31 13:31 ` [PATCH 2/6] ASoC: ab8500: Inform SoC Core that we have our own I/O arrangements Lee Jones
2012-07-31 13:31 ` [PATCH 3/6] ARM: ux500: Fix merge error, so such struct 'snd_soc_u8500' Lee Jones
2012-07-31 16:46   ` Sergei Shtylyov
2012-08-01  7:37     ` Lee Jones
2012-08-01  8:19       ` Lee Jones
2012-08-01  8:46   ` [PATCH 3/6 v2] ARM: ux500: Fix merge error, no matching driver name for, 'snd_soc_u8500' Lee Jones
2012-07-31 13:31 ` [PATCH 3/6] ARM: ux500: Remove unused snowball_of_platform_devs struct Lee Jones
2012-07-31 20:58   ` Arnd Bergmann
2012-07-31 13:31 ` [PATCH 4/6] ARM: ux500: Ensure probing of Audio devices when Device Tree is enabled Lee Jones
2012-07-31 13:31 ` [PATCH 4/6] ARM: ux500: Fix merge error, so such struct 'snd_soc_u8500' Lee Jones
2012-07-31 20:58   ` Arnd Bergmann
2012-07-31 13:31 ` [PATCH 5/6] ARM: ux500: Enable HIGHMEM on all mop500 platforms Lee Jones
2012-07-31 13:56   ` Russell King - ARM Linux
2012-07-31 14:29     ` Lee Jones
2012-07-31 14:37       ` Russell King - ARM Linux
2012-07-31 20:50         ` Arnd Bergmann
2012-07-31 22:01           ` Russell King - ARM Linux
2012-08-01  7:56             ` Lee Jones
2012-08-01  8:41               ` Russell King - ARM Linux
2012-08-01  8:48                 ` Lee Jones
2012-07-31 13:31 ` [PATCH 5/6] ARM: ux500: Ensure probing of Audio devices when Device Tree is enabled Lee Jones
2012-07-31 20:54   ` Arnd Bergmann
2012-08-01  7:34     ` Lee Jones
2012-08-01 13:32       ` Arnd Bergmann
2012-08-01 13:55         ` Lee Jones
2012-08-01 14:32           ` Arnd Bergmann
2012-07-31 13:31 ` [PATCH 6/6] ARM: ux500: Enable HIGHMEM on all mop500 platforms Lee Jones
2012-07-31 13:31 ` [PATCH 6/6] ASoC: Ux500: Move MSP pinctrl setup into the MSP driver Lee Jones
2012-07-31 13:40 ` [PATCH 1/6] Bugfixes and clean-ups bound for the v3.6 RCs Mark Brown
2012-07-31 14:30   ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120802074517.GA19231@gmail.com \
    --to=ljkenny@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).