![](https://seccdn.libravatar.org/avatar/324f26b736d3eb90435dbe1c3d1a2dc2.jpg?s=120&d=mm&r=g)
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.
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. I think it would be more logical to ship multiple series.conf in one src.rpm. series.conf *into one* src.rpm.
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).
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 ;-) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org