I'd very much prefer Debian kernel maintainers would accept patches from the
respective architecture maintainers' tree, but that may not come to happen in
my lifetime.
Probably not. On the other hand, things that don’t get into
3.2-stable won’t end up there either way during the freeze.
We could conceivably make a “floating” v3.2+debian+m68k tree.
I’d start that by making *one* commit on top of v3.2.x (stable)
letting it match the Debian tree of that version, then adding
those patches we need (fixes like this come to mind, and HW
drivers – I can’t judge what is good (or stable) and what not,
you’d have to volunteer for that, but I don’t want to apply
all of v3.2+m68k blindly, especially considering m68k-queue
has moved on to 3.5/3.6 now); then I can build packages for
debian-ports unreleased from that.
Which has the detriment of not having an ABI guarantee any
more (since I have no idea how to verify that I’d bump it
with every upload), and sort of spitting into the Debian
kernel maintainers’ face after all their accomodating our
SCC architecture needs (in fact, except for this bugfix,
the shipped Atari and Amiga kernels at least are known to
work on *some* hardware, just the Atari kernel lacks drivers
for some network cards).
So, what do you think? Personally, I see benefits for sticking
with Debian kernels for as long as they work, it’s called
dogfooding ☺ and they do work for Amiga and ARAnyM buildds.
Besides, (too) many m68k people are used to roll their own
kernels anyway, so I think catering to them is overkill.