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
next prev parent 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