On Sat, 2009-08-29 at 21:51 +0200, Jan Engelhardt wrote:
On Saturday 2009-08-29 21:10, Sven-Thorsten Dietrich
the RT Kernel is indeed separately maintained (by me).
There are a variety of different reasons for this:
2. Patch logistics. While in development, its easier to place the RT
mega-patch early in the series, and then to resolve the conflicts in the
subsequent Suse patch queue. (Based on the notion, that its easier and
less error-prone to refresh / resolve smaller patches).
Maybe I should just strip all the SUSE patches from my series.conf
because I am not really interested in them and they are only in the
way in the decent-but-recent-RT-stability project I am pursuing.
In this development phase, there is actually a lot of duplication; e.g.
RT and Suse both carried various audio patch sets for a while - now
these seem to be merged into Linus's tree for the most part.
That sort of back and forth ends up happening, and its definitely easier
to mod/drop the smaller patches.
During the support cycle, its nice to have the security and critical fix
stream generated by the Suse Kernel folks, as well as some of the driver
We have looked at the +RT guards, but based on the
patch queue, you
would end up with messy stuff like this:
So we end up with 2 versions of the same patch, caused by conflicts with
RT. That ends up severely cluttering the patch queue.
series.conf is not the main problem, the rest is.
Because now everybody wanting to add patches or modifying other
parts, such as the .spec(.in) files or anything else has to do that
to two packages. It's like we are back to providing only .spec
files and no master .spec.in.
Last time I checked, RT and HEAD were using almost identical spec files.
The diffs were in declaring the RT variant and other odd bits.
I think it would be more logical to ship multiple
series.conf in one
src.rpm. series.conf *into one* src.rpm.
This would help with the KMP problem as well... common source would be
nice. At Suse, these are very separate projects with different
objectives, management, etc. and right or wrong, are treated as such.
Not much I can do to push the envelope.
(once development moves past 2.6.31), I will use the +RT
guard with RT at the end of the Suse patch queue.
I will resolve the conflicts and adding small fixups individually per
interdiff or from upstream git.
That would mean a state where the tree would not compile and/or run
properly, hurting bisectability (and yes, I do have to do that
sometimes with the entire patch queue).
The old broken-out RT patch set is now several git branches. I haven't
scoped how straightforward it would be to break things out.
But as is, with the megapatch we are using right now, that
bisectability is out the window.
Plan is eventually to get back to broken-out patch set.
Of course: The ideal situation would be to apply
the RT patch
unconditionally, and then work with config/flavors to enable the various
I am doing that already, but thanks for trying ;-)
Thanks for the feedback - lets maybe discuss more FTF in Dresden?
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org