All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] sh-pfc: r8a7779: Don't group USB OVC and PENC pins
Date: Sat, 01 Jun 2013 04:35:44 +0000	[thread overview]
Message-ID: <20130601043544.GA4267@quad.lixom.net> (raw)
In-Reply-To: <CACRpkda9tjydo038exS2a=Gsvum41LyvXd=GwKh3b0Zi4rOA9g@mail.gmail.com>

On Fri, May 31, 2013 at 09:21:46AM +0200, Linus Walleij wrote:
> On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <olof@lixom.net> wrote:
> > [Simon]
> >> As an aside, I do expect to send some more v3.10 fixes for shmobile.
> >> There seem to be more than usual.
> >
> > A little unfortunate but it's hard to do much about.
> >
> > Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
> > has said he really wants to see things slow down.
> 
> What we might need to think about is the evolutional pace of the ARM
> kernel - compared to a few years back we have increased the change
> rate by orders of a magnitude (at least that is my feeling...)

Oh, very much so. And there's a lot of additions of new code.

Linus clarified just this week at LC Japan what ticks him off about -rc
patches too; it's an indication that people aren't sending code that's
baked and tested enough during the merge window, causing all these fixes
on top.

Given the rate of change of arm platforms, some of this is definitely
expected (i.e. proportional to amount of merge window changes). Still,
we have empirical evidence that far from all maintainers keep a close
eye on linux-next status for their platforms. :-)

I have a small board farm that I make sure boot more or less daily
with linux-next now, but my space is limited. It also shouldn't be my
responsibility to make sure that various platforms keep working; it's
up to each submaintainer to do so.

That doesn't mean there won't be corner cases still, hardware that
maintainers don't have themselves affected, etc. But by keeping an eye
on linux-next, a handful of -rc fixes can be avoided.

> There may be some point where we actually need to tell people to
> hold changes back because they are just pushing too large volumes
> through one merge window, resulting in a corresponding amount of
> fixes.

That's essentially what we did with the initial multiplatform changes for 3.10
for Exynos, where they seemed to need more bake time and got held off.

> This merge window both Samsung Exynos and SH mobile seem to
> have been a little bit trigger-happy :-/

Both of them saw a lot of changes. Exynos saw the onslaught of Linaro
engineers starting to work more on Arndale, and shmobile saw a huge
amount of changes due to their cutting over subsystems. The latter
is hard to avoid since it can be complicated to keep both old and new
infrastructure around, and the former we should just make sure to catch
with linux-next testing.

But you do bring up valid points, and it's something to keep in mind going
forward.


-Olof


WARNING: multiple messages have this Message-ID (diff)
From: olof@lixom.net (Olof Johansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] sh-pfc: r8a7779: Don't group USB OVC and PENC pins
Date: Fri, 31 May 2013 21:35:44 -0700	[thread overview]
Message-ID: <20130601043544.GA4267@quad.lixom.net> (raw)
In-Reply-To: <CACRpkda9tjydo038exS2a=Gsvum41LyvXd=GwKh3b0Zi4rOA9g@mail.gmail.com>

On Fri, May 31, 2013 at 09:21:46AM +0200, Linus Walleij wrote:
> On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <olof@lixom.net> wrote:
> > [Simon]
> >> As an aside, I do expect to send some more v3.10 fixes for shmobile.
> >> There seem to be more than usual.
> >
> > A little unfortunate but it's hard to do much about.
> >
> > Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
> > has said he really wants to see things slow down.
> 
> What we might need to think about is the evolutional pace of the ARM
> kernel - compared to a few years back we have increased the change
> rate by orders of a magnitude (at least that is my feeling...)

Oh, very much so. And there's a lot of additions of new code.

Linus clarified just this week at LC Japan what ticks him off about -rc
patches too; it's an indication that people aren't sending code that's
baked and tested enough during the merge window, causing all these fixes
on top.

Given the rate of change of arm platforms, some of this is definitely
expected (i.e. proportional to amount of merge window changes). Still,
we have empirical evidence that far from all maintainers keep a close
eye on linux-next status for their platforms. :-)

I have a small board farm that I make sure boot more or less daily
with linux-next now, but my space is limited. It also shouldn't be my
responsibility to make sure that various platforms keep working; it's
up to each submaintainer to do so.

That doesn't mean there won't be corner cases still, hardware that
maintainers don't have themselves affected, etc. But by keeping an eye
on linux-next, a handful of -rc fixes can be avoided.

> There may be some point where we actually need to tell people to
> hold changes back because they are just pushing too large volumes
> through one merge window, resulting in a corresponding amount of
> fixes.

That's essentially what we did with the initial multiplatform changes for 3.10
for Exynos, where they seemed to need more bake time and got held off.

> This merge window both Samsung Exynos and SH mobile seem to
> have been a little bit trigger-happy :-/

Both of them saw a lot of changes. Exynos saw the onslaught of Linaro
engineers starting to work more on Arndale, and shmobile saw a huge
amount of changes due to their cutting over subsystems. The latter
is hard to avoid since it can be complicated to keep both old and new
infrastructure around, and the former we should just make sure to catch
with linux-next testing.

But you do bring up valid points, and it's something to keep in mind going
forward.


-Olof

  parent reply	other threads:[~2013-06-01  4:35 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29 22:28 [GIT PULL] Renesas ARM based SoC fixes for v3.10 Simon Horman
2013-05-29 22:28 ` Simon Horman
2013-05-29 22:28 ` [PATCH 1/2] sh-pfc: r8a7779: Don't group USB OVC and PENC pins Simon Horman
2013-05-29 22:28   ` Simon Horman
2013-05-29 22:35   ` Sergei Shtylyov
2013-05-29 22:35     ` Sergei Shtylyov
2013-05-29 23:51     ` Laurent Pinchart
2013-05-29 23:51       ` Laurent Pinchart
2013-05-30 11:50       ` Sergei Shtylyov
2013-05-30 11:50         ` Sergei Shtylyov
2013-05-30 20:08   ` Linus Walleij
2013-05-30 20:08     ` Linus Walleij
2013-05-31  0:17     ` Simon Horman
2013-05-31  0:17       ` Simon Horman
2013-05-31  4:43       ` Olof Johansson
2013-05-31  4:43         ` Olof Johansson
2013-05-31  5:45         ` Simon Horman
2013-05-31  5:45           ` Simon Horman
2013-05-31  6:11           ` Olof Johansson
2013-05-31  6:11             ` Olof Johansson
2013-05-31  7:21             ` Linus Walleij
2013-05-31  7:21               ` Linus Walleij
2013-05-31 23:59               ` Simon Horman
2013-06-01  0:00                 ` Simon Horman
2013-06-01  4:35               ` Olof Johansson [this message]
2013-06-01  4:35                 ` Olof Johansson
2013-05-31  7:43             ` Simon Horman
2013-05-31  7:43               ` Simon Horman
2013-05-29 22:28 ` [PATCH 2/2] ARM: shmobile: sh73a0: Update CMT clockevent rating to 80 Simon Horman
2013-05-29 22:28   ` Simon Horman
2013-06-01  4:41 ` [GIT PULL] Renesas ARM based SoC fixes for v3.10 Olof Johansson
2013-06-01  4:41   ` Olof Johansson
2013-06-07  8:05   ` Simon Horman
2013-06-07  8:05     ` Simon Horman
  -- strict thread matches above, loose matches on Subject: below --
2013-06-04  7:46 [GIT PULL v3] " Simon Horman
2013-06-04  7:46 ` [PATCH 1/2] sh-pfc: r8a7779: Don't group USB OVC and PENC pins Simon Horman
2013-06-04  7:46   ` Simon Horman

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=20130601043544.GA4267@quad.lixom.net \
    --to=olof@lixom.net \
    --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 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.