On Sat, 2009-08-29 at 21:51 +0200, Jan Engelhardt wrote:
On Saturday 2009-08-29 21:10, Sven-Thorsten Dietrich wrote:
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 freshening.
We have looked at the +RT guards, but based on the patch queue, you would end up with messy stuff like this:
+RT patch-2.6.X-Y-rtZ .. other patches .. -RT suse_patch-abc +RT suse_patch-abc.rt .. 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.
Eventually (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 features.
I am doing that already, but thanks for trying ;-)
Thanks for the feedback - lets maybe discuss more FTF in Dresden? Sven -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org