[opensuse-kernel] Putting HEAD into git
Hi, 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? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jan Engelhardt napsal(a):
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, 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). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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? 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. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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
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
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
On Sunday 2009-08-30 08:28, Sven-Thorsten Dietrich wrote:
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.
I am not quite sure what you try to showcase. It is possibly true that SUSE can patch their kernel rpm faster than waiting for the next -stable update to contain a security fix, but on the other hand I have also seen SUSE not providing all -stable updates either, sometimes letting time seemingly pass, and skipping things like 2.6.25.11 -> 2.6.25.16.
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.
What I am saying is that if modifications to kernel/some.spec is made, you also have to make the changes to kernel-rt/some.spec. In its simplest case it is a /bin/cp operation, but it may not. Either way, it is extra work.
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...
I do not see how this would relate. Whether one .src.rpm produces {kernel, kernel-source, kernel-rt, kernel-rt-source} packages, or two .src.rpms produce {kernel, kernel-source} {kernel-rt, kernel-rt-source} does not make much of a difference to the user. If you however mean kernel-source (yes, it is now known under a new name..) containing both kernel-source and kernel-rt-source — hey, cool idea — you may want to use fdupes. Does not rpm already do fdupes automatically?
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.
I meant bisecting the SUSE patch gubble and whatever else I added (after all, they make up the majority of series.conf), not upstream patches. I think upstream is best left as megapatches, and I find it simpler to just provide patches.kernel/2.6.31-rc7 [56729KB] instead of patches.kernel/2.6.31-rc1 + patch-2.6.31-rc1-rc2 + ... -rc6-rc7 [totalling 59505KB], simply for size. They should be reasonably correct.
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?
What is in Dresden? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Sun, 2009-08-30 at 12:47 +0200, Jan Engelhardt wrote:
On Sunday 2009-08-30 08:28, Sven-Thorsten Dietrich wrote:
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.
I am not quite sure what you try to showcase. It is possibly true that SUSE can patch their kernel rpm faster than waiting for the next -stable update to contain a security fix, but on the other hand I have also seen SUSE not providing all -stable updates either, sometimes letting time seemingly pass, and skipping things like 2.6.25.11 -> 2.6.25.16.
Stable expires usually within 2 revs of the Kernel, well before the Kernel support for OpenSUSE, so therein lies the value add of the Suse Kernel. In regards to the issue of stable updates, often individual patches that make up a stable release are put into the Kernel tree before the stable release hits upstream. Dropping them back out and replacing with stable is then not time critical, since the broken out components are in the tree. This may go on for several releases, which may be in-part causing the skipped stable releases. Whether things are complete or lagging at any given point or for a specific Kernel is a matter of forensics. Whatever isn't covered by the above - its true that we all would like to have more time, more engineers, and more QA to get things out faster, but we all are doing what we can with what we've got. And we do appreciate the input. Hopefully the git tree will help make things easier whenever that is made available.
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.
What I am saying is that if modifications to kernel/some.spec is made, you also have to make the changes to kernel-rt/some.spec. In its simplest case it is a /bin/cp operation, but it may not. Either way, it is extra work.
We will work towards that in the future.
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...
I do not see how this would relate. Whether one .src.rpm produces {kernel, kernel-source, kernel-rt, kernel-rt-source} packages, or two .src.rpms produce {kernel, kernel-source} {kernel-rt, kernel-rt-source} does not make much of a difference to the user.
If you however mean kernel-source (yes, it is now known under a new name..) containing both kernel-source and kernel-rt-source — hey, cool idea — you may want to use fdupes. Does not rpm already do fdupes automatically?
I am honestly not familiar enough with all the intricacies / dependencies / requirements of the build system, so I can't answer that in a useful manner. We spent quite some time talking about the RT issue, and maintaining separately seemed to be the best option at least for the near- to mid- term.
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.
I meant bisecting the SUSE patch gubble and whatever else I added (after all, they make up the majority of series.conf), not upstream patches.
I think upstream is best left as megapatches, and I find it simpler to just provide patches.kernel/2.6.31-rc7 [56729KB] instead of patches.kernel/2.6.31-rc1 + patch-2.6.31-rc1-rc2 + ... -rc6-rc7 [totalling 59505KB], simply for size. They should be reasonably correct.
Here I am just following with RT what other people are doing, so that is not up to me, but its the right list :)
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?
What is in Dresden?
I will be there for the RT Linux Foundation Meeting end of September. Sven -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jan Engelhardt napsal(a):
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?
Sorry, not yet. People (including me) are on vacation randomly and things aren't moving as fast :(.
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.
They are separately maintained. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Michal Marek
Jan Engelhardt napsal(a):
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?
Sorry, not yet. People (including me) are on vacation randomly and things aren't moving as fast :(.
Any update on the kernel repository? -Joachim p.s. resending due to html email hatred by the listserv -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (4)
-
Jan Engelhardt -
Joachim Deguara -
Michal Marek -
Sven-Thorsten Dietrich