From: khc@pm.waw.pl (Krzysztof Halasa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PULL REQ] IXP4xx changes for Linux 3.7
Date: Thu, 18 Oct 2012 00:01:17 +0200 [thread overview]
Message-ID: <m3a9vkahci.fsf@intrepid.localdomain> (raw)
In-Reply-To: <201210142002.55841.arnd@arndb.de> (Arnd Bergmann's message of "Sun, 14 Oct 2012 20:02:55 +0000")
Hi,
Arnd Bergmann <arnd@arndb.de> writes:
> as mentioned before, all arch/arm/mach-* patches should go through the
> arm-soc tree or get an Ack from the arm-soc maintainers. The same thing
> is true for the char-misc and the crypto trees.
You've seen the changes. They were trivial fixes, touched only
IXP4xx-related areas, there was nothing related to char or crypto
subsystems there, except file location (well, IXP4xx drivers have to be
located somewhere).
The patches have been posted to linux-arm-kernel and you knew about
them. That they were obviously correct and clean is probably not
that important.
Nobody bothered to comment the patches.
> Also, never rebase your tree immediately before sending a pull
> request.
I did not, of course. My mail stated:
"Build-tested for now. This is based on your current tree tip because it
depends on commits following 3.6 release."
Normally I wouldn't rebase, but had to (as you well knew) - because you
commited a conflicting patch to this very IXP4xx arch. Using your logic,
you were supposed to get an Ack from me (or from Imre) for this patch.
Actually it wasn't a problem for me, I simply had to rebase.
> Finally when sending bug fixes, please annotate any patches with
> 'Cc: stable at vger.kernel.org' if they address bugs that are already
> present in older kernels, so that the stable and longterm maintainers
> can easily backport the fixes.
I do that when I think it makes sense. In this case (two patches for
Goramo MultiLink platform) practically all such devices use kernels
prepared by me, and I think Greg (and others) have more efficient ways
to spend their time than handling almost unused patches. Also, I have
much more efficient ways to spend time. Anyway, if I can't have my
patches upstream, why should they end up in stable?
> Almost all of the platform patches in your tree seem to be bug fixes,
> so they are still good for inclusion in v3.7 if you submit them to
> arm-soc soon, but please make sure you separate bug fixes from other
> changes so we can group them appropriately when forwarding them to
> Linus.
Unfortunately, as I already explained to you in
https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very
limited (and this isn't a paid job) and I'm in no way able to do what
you require. This, coupled with my inability to make the patches end up
upstream any other way, will make me post relevant MAINTAINERS changes
shortly.
Don't get me wrong. If I had time for this it could be different.
Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at
this point. Given the raised barriers to participate, probably aimed at
paid maintainers, I have to quit doing this.
BTW since Imre has probably even much less time, it would be a good time
to find someone to maintain IXP4xx code. I will be publishing (from time
to time) my tree (I'm using the hw myself), so even simple
cherry-picking would probably make some sense.
--
Krzysztof Halasa
next prev parent reply other threads:[~2012-10-17 22:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-13 21:22 [PULL REQ] IXP4xx changes for Linux 3.7 Krzysztof Halasa
2012-10-14 20:02 ` Arnd Bergmann
2012-10-17 22:01 ` Krzysztof Halasa [this message]
2012-10-19 16:25 ` Jason Cooper
2012-10-29 8:29 ` Richard Cochran
2012-10-30 22:27 ` Arnd Bergmann
2012-10-31 13:24 ` Jason Cooper
2012-10-29 9:55 ` Russell King - ARM Linux
2012-10-30 0:46 ` Ryan Mallon
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=m3a9vkahci.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