On Sat, 2009-08-29 at 16:22 +0200, Jan Engelhardt wrote:
On Wednesday 2009-08-05 21:42, Jan Engelhardt wrote:
to date, the opensuse kernel git repository (git.opensuse.org/people/jblunck/kernel-source.git) has only seen two updates:
- on the 11.1 release party last year, or shortly before that
- about 2 weeks ago
Is there a reason for this irregular push pattern?
That's not "the opensuse kernel git repository" but some private clone created by Jan [Blunck], with only the master branch. We're working on a "official", automatically synced, mirror which should be available really soon (next week or the week after that).
3½ weeks, did it get somewhere?
I will forward CC of this to the internal Suse Kernel list and ask.
What is also quite irritating is that the two kernel-source.src.rpms (one standard, one rt) in {repositories}/Kernel:/HEAD/ have differing series.conf and so. That may be due to either being newer (as evident from the package release numbers), but in that case both rpms should have been built automatically in lockstep (or shortly after another). Or, these two .src.rpms are wholly separately maintained, which I would question why one would do that. Not even I needed to do _that_. I mean, series.conf can have "+RT" in front of rt patches, yet it does not.
Hi Jan, the RT Kernel is indeed separately maintained (by me). There are a variety of different reasons for this: 1. Schedule (the OpenSUSE schedule has been set, the SLERT 11 product schedule is still being determined). 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). 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. 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. But during this high-flux phase, putting RT at the end of the Suse patch queue is futile. I'd end up resolving the same conflicts in a most error-prone manner, over and over, with changes in both RT and the Suse 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 don't think this will be possible at Suse until more of RT has been merged upstream. Meanwhile, the latest RT RPMS are always available here: http://download.opensuse.org/repositories/home://sdietrich://Kernel-RT/openS... I hope that clears it up a little - I am always available for suggestions / questions / discussion; this isn't an exact science, but based on the last 3 years, I think I have found the highest quality approach to the solution. Regards, Sven -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org