public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: khc@pm.waw.pl (Krzysztof Halasa)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO
Date: Sat, 29 Sep 2012 19:02:36 +0200	[thread overview]
Message-ID: <m3y5jskbir.fsf@intrepid.localdomain> (raw)
In-Reply-To: <201209291458.16112.arnd@arndb.de> (Arnd Bergmann's message of "Sat, 29 Sep 2012 14:58:15 +0000")

Arnd Bergmann <arnd@arndb.de> writes:

>> Could you please point me to a statement requiring eg. my changes to go
>> through arm-soc?
>
> We've been doing it like this for some time. Stephen Warren replied
> to your request to add your tree to linux-next in
>
> http://comments.gmane.org/gmane.linux.kernel/1356118
>
> explaining how it works. Olof sent a mail last week in 
>
> http://lkml.org/lkml/2012/9/21/31
>
> explaining that we're closing the window for 3.7 except for a
> few things that were already submitted earlier.

No offense, but... You say how does it work for YOU but that's not
exactly what I'm asking for. I'm asking for a statement that it's not OK
for me to push my IXP4xx changes straight to Linus.

> The arm-soc process is definitely meant to make your life easier
> as well as help Linus understand what's going on with all of ARM
> to the degree that he needs to know, but it only works if everyone
> participates.

I'd like to know how is it easier for me. Actually, I think it would
only make things worse for everyone (mostly for me). Also, I can't see
how "it only works if everyone participates" is true.

I'm currently supporting (for our internal needs) hw platforms based
on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required
so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current
tree since it's the next stable. The hw is e.g. Gateworks' platforms
with code taken from e.g. OpenWRT. I hope to have most of this in Linus'
tree when it's eventually ready. Unfortunately, I'm just one man, and
the above is only a slim part of my work. Egoistically, I don't think
I'm currently willing to spend time with arm-soc tree, if I can't see
any real technical benefit to anyone.

It would be different if my tree included e.g. core ARM changes - but it
doesn't. What's the _real_ reason for asking me to push my changes
indirectly?

Also, not that it's the most important, but how is it better for anyone
to delay changes - which are completely orthogonal to arm-soc - for
additional months? Doesn't "release early, release often" make sense
anymore?
-- 
Krzysztof Halasa

  reply	other threads:[~2012-09-29 17:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-28 21:36 [PATCH 00/12] New warnings and build errors in linux-next Arnd Bergmann
2012-09-28 21:36 ` [PATCH 01/12] mtd: atmel nand: build regression Arnd Bergmann
2012-09-29 19:53   ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 21:36 ` [PATCH 02/12] ata: mark probe function as __devinit rather than __init Arnd Bergmann
2012-09-28 21:38   ` Mark Langsdorf
2012-09-28 21:36 ` [PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module Arnd Bergmann
2012-10-01 11:05   ` Will Newton
2012-10-04 12:40     ` Seungwon Jeon
2012-09-28 21:36 ` [PATCH 04/12] video: exynos: warnings in exynos_dp_core.c Arnd Bergmann
2012-10-05  8:01   ` Jingoo Han
2012-10-05  8:16     ` Arnd Bergmann
2012-09-28 21:36 ` [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO Arnd Bergmann
2012-09-29 10:35   ` ARM SoC tree, Was: " Krzysztof Halasa
2012-09-29 14:58     ` Arnd Bergmann
2012-09-29 17:02       ` Krzysztof Halasa [this message]
2012-09-29 17:31         ` Olof Johansson
2012-09-29 17:44         ` Russell King - ARM Linux
2012-09-29 21:38           ` Krzysztof Halasa
2012-09-29 21:53             ` Russell King - ARM Linux
2012-09-30 17:01               ` Krzysztof Halasa
2012-09-28 21:36 ` [PATCH 06/12] sched: warnings in kernel/sched/fair.c Arnd Bergmann
2012-09-28 21:36 ` [PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio Arnd Bergmann
2012-09-29 10:02   ` Jonathan Cameron
2012-09-29 15:03     ` Arnd Bergmann
2012-10-13  9:54       ` Jonathan Cameron
2012-09-28 21:36 ` [PATCH 08/12] dtc: be more quiet with "make -s" Arnd Bergmann
2012-09-28 21:55   ` Stephen Warren
2012-09-29  7:27     ` Arnd Bergmann
2012-09-28 21:36 ` [PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c Arnd Bergmann
2012-09-28 21:45   ` Jason Wessel
2012-10-22 23:37     ` Greg Kroah-Hartman
2012-09-28 21:36 ` [PATCH 10/12] gpio: pcf857x: select IRQ_DOMAIN Arnd Bergmann
2012-09-30 21:39   ` Linus Walleij
2012-09-28 21:36 ` [PATCH 11/12] pinctrl: samsung: use __devinit section for init code Arnd Bergmann
2012-10-01  6:15   ` Linus Walleij
2012-10-02 11:52     ` Arnd Bergmann
2012-10-02 12:57       ` Linus Walleij
2012-10-02 20:28   ` Thierry Reding
2012-09-28 21:36 ` [PATCH 12/12] time/jiffies: bring back unconditional LATCH definition Arnd Bergmann
2012-09-28 21:55   ` John Stultz

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=m3y5jskbir.fsf@intrepid.localdomain \
    --to=khc@pm.waw.pl \
    --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