schmitz dixit:
> We may need to keep a few extra patches against a stable kernel version (on top
> of the Debian patch set) for some time.
Right.
> 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.
I’d rather fix Iceweasel, Webkit and OpenJDK. And work on
them bootloaders.
bye,
//mirabilos
--
<Natureshadow> Dann mach ich git annex copy --to shore und fertig ist das
<Natureshadow> das ist ja viel cooler als ownCloud ...
<mirabilos> sag ich doch
<Natureshadow> ja wieso stimmt das denn immer was du sagst ...