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 23:38:31 +0200 [thread overview]
Message-ID: <m3pq54jyqw.fsf@intrepid.localdomain> (raw)
In-Reply-To: <20120929174400.GA6933@n2100.arm.linux.org.uk> (Russell King's message of "Sat, 29 Sep 2012 18:44:01 +0100")
I realize my work flow is probably suboptimal, though I can't see
an easy solution.
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> That makes no sense what so ever. The tree which is used for the next
> stable tree will be Linus' tree, which will be the result of merging all
> those other trees into Linus' tree. If you base your changes off only
> Linus' tree on the run up to the next merge window, then you are preparing
> your changes against an _older_ kernel than if you base them off a tree
> containing the changes which will be _included_ in the next merge
> window.
Yes. I have to fix my tree and ask for pull before the end of merge
window (fixes could follow, but it's best when there are no fixes
needed). I know it's not a great plan. Fortunately I'm not doing heavy,
conflicting development on this.
Note I'm not only doing ARM, but also X86 and MIPS, with additional code
shared between them, and the "stable" part of it is what I'm paid for.
I can't simply work with arm-soc, none of my platforms will even boot
with pure arm-soc.
> If you want to work in total isolation, that's your choice, but in the
> long run you will be playing catch-up rather than being prepared early
> for the changes which will happen at the next merge window. If you want
> -rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to
> fixing up the merge window breakage, then go ahead.
>
> Otherwise, participate and be part of the community, and get your changes
> into arm-soc, so that others can see what's going on.
Unfortunately this seems to require more time on my part, time I don't
have. Perhaps I'm missing something?
I.e., I can dedicate some time around the merge window (not every one,
but this may improve), but not much more.
I don't think there are any "others" interested in what's going on on
IXP4xx. Simply, there isn't anything of importance here. It won't cause
severe conflicts (and "next" helps here), and I post my patches to the
list just like all people do.
Of course if you can see a better way (given the limitations), I'm open.
BTW I still think I'm a part of the community, even if I don't submit
code through arm-soc :-)
--
Krzysztof Halasa
next prev parent reply other threads:[~2012-09-29 21:38 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
2012-09-29 17:31 ` Olof Johansson
2012-09-29 17:44 ` Russell King - ARM Linux
2012-09-29 21:38 ` Krzysztof Halasa [this message]
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=m3pq54jyqw.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