Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Ola Lilja <ola.o.lilja@stericsson.com>,
	alsa-devel@alsa-project.org,
	Fabio Baltieri <fabio.baltieri@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/6] ASoC: ux500: Do not clear state if already idle
Date: Wed, 8 May 2013 14:48:14 +0100	[thread overview]
Message-ID: <20130508134814.GQ7478@sirena.org.uk> (raw)
In-Reply-To: <20130508130554.GG3459@gmail.com>


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

On Wed, May 08, 2013 at 02:05:54PM +0100, Lee Jones wrote:

> I'm saying, from experience, from the developer side, that if a
> reviewer goes though a patch-set taking the ones s/he likes leaving
> the rest behind, there are bound to be merge conflicts and semantic
> issues which the developer will then have to resolve. Stuff that I
> believe is added, unnecessary burden which would be easily avoided if
> the set is firstly reviewed and _then_ applied after the Acks have
> been awarded.

So, you have to assume a bit of taste on the part of the people applying
the patches here.  If you're seeing merge conflicts that's probably an
issue, but then it's very surprising that the patches would apply
successfully in the first place since the conflicts generally come up
when the patches are applied too.

The other thing to bear in mind here is that a patch series which is
"here's a bunch of random changes to this driver" isn't the same as a
patch series which builds something up through a series of changes.
This series is a good example of the former - there's a few related
things but really there's no visible relationship between most of the
changes except that they happen to be for the same driver and sent at
the same time.

The big downsides of not applying patches are that it takes longer to
get the benefit of the bits that are good out to people and the big
increase in reviewer fatigue from having to re-read the same patches
over and over again.  This is one of the major ways problematic code
gets in, reviewers eyes glaze over and they just start missing things.
There's also the fact that serieses often end up having separate bugfix
and development components which need to be routed differently anyway.

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

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



  reply	other threads:[~2013-05-08 13:48 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-08  7:14 [PATCH 0/6] Second set of fixes for ux500 ASoC drivers Fabio Baltieri
2013-05-08  7:14 ` [PATCH 1/6] ASoC: ab8500-codec: Add missing ad_to_slot definitions Fabio Baltieri
2013-05-08  7:53   ` Lee Jones
2013-05-08  8:30     ` Fabio Baltieri
2013-05-08  8:47       ` Lee Jones
2013-05-08 10:58   ` Mark Brown
2013-05-08  7:14 ` [PATCH 2/6] ASoC: ux500: Do not clear state if already idle Fabio Baltieri
2013-05-08  8:04   ` Lee Jones
2013-05-08  8:39     ` [PATCH v2 " Fabio Baltieri
2013-05-08 10:34       ` Mark Brown
2013-05-08 11:04         ` Lee Jones
2013-05-08 11:31           ` Mark Brown
2013-05-08 12:03             ` Lee Jones
2013-05-08 12:39               ` Mark Brown
2013-05-08 13:05                 ` Lee Jones
2013-05-08 13:48                   ` Mark Brown [this message]
2013-05-08 14:06                     ` Lee Jones
2013-05-09  9:28                       ` Mark Brown
2013-05-08 12:04         ` Fabio Baltieri
2013-05-08 12:39           ` Mark Brown
2013-05-08  7:14 ` [PATCH 3/6] ASoC: ux500: Drop pinctrl sleep support Fabio Baltieri
2013-05-08  8:07   ` Lee Jones
2013-05-08  8:20     ` Fabio Baltieri
2013-05-08  8:48       ` Lee Jones
2013-05-08  9:00         ` Fabio Baltieri
2013-05-08 10:51   ` Mark Brown
2013-05-08 11:42     ` Fabio Baltieri
2013-05-08 12:32       ` Mark Brown
2013-05-08 13:10         ` Fabio Baltieri
2013-05-08 13:54           ` Mark Brown
2013-05-08 14:17             ` Fabio Baltieri
2013-05-08 14:27               ` Fabio Baltieri
2013-05-08 14:49                 ` Mark Brown
2013-05-08 15:07                   ` Lee Jones
2013-05-09  9:34                     ` Mark Brown
2013-05-08 14:29               ` Mark Brown
2013-05-08 15:48                 ` Fabio Baltieri
2013-05-09  9:41                   ` Mark Brown
2013-05-13 10:43                     ` Fabio Baltieri
2013-05-17 22:02                   ` Linus Walleij
2013-05-08  7:14 ` [PATCH 4/6] ASoC: ux500: Update tx tdm slots configuration Fabio Baltieri
2013-05-08  8:18   ` Lee Jones
2013-05-08 11:01   ` Mark Brown
2013-05-08 11:11     ` Lee Jones
2013-05-08 11:32       ` Fabio Baltieri
2013-05-08 12:28       ` Mark Brown
2013-05-08 16:03     ` Fabio Baltieri
2013-05-08  7:14 ` [PATCH 5/6] ASoC: ux500: Swap even/odd AD slot definitions Fabio Baltieri
2013-05-08  8:19   ` Lee Jones
2013-05-08  7:14 ` [PATCH 6/6] ASoC: ux500: Use the first two AD slots for capture Fabio Baltieri
2013-05-08  8:22   ` Lee Jones
2013-05-08 10:56   ` Mark Brown
2013-05-08 11:12     ` Lee Jones
2013-05-08 12:30       ` Mark Brown
2013-05-08 16:08     ` Fabio Baltieri

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=20130508134814.GQ7478@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=fabio.baltieri@linaro.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ola.o.lilja@stericsson.com \
    /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