Hi All,
If you've been watching rawhide the past couple of days, you've seen that the kernel has started moving to the 3.20 merge window kernels. At the moment, rawhide and the f22 branch will remain in-sync. Things have, so far, gone fairly smoothly in local testing. Feedback from others would be appreciated.
Looking at the Fedora 22 release schedule, it is most likely that we will wind up shipping with a stable release of the 3.20 series. That means the more testing we get on the kernel now, the better shape it should theoretically be in when we ship. Barring any delays on the Fedora side of things (because those never happen), that will be the plan going forward.
Rawhide and the f22 branch will diverge when the v3.21 window opens up.
If you have any questions/comments, let us know.
josh
On Thu, 2015-02-12 at 16:31 -0500, Josh Boyer wrote:
Hi All,
If you've been watching rawhide the past couple of days, you've seen that the kernel has started moving to the 3.20 merge window kernels. At the moment, rawhide and the f22 branch will remain in-sync. Things have, so far, gone fairly smoothly in local testing. Feedback from others would be appreciated.
Looking at the Fedora 22 release schedule, it is most likely that we will wind up shipping with a stable release of the 3.20 series. That means the more testing we get on the kernel now, the better shape it should theoretically be in when we ship. Barring any delays on the Fedora side of things (because those never happen), that will be the plan going forward.
Rawhide and the f22 branch will diverge when the v3.21 window opens up.
If you have any questions/comments, let us know.
At the moment, we are leaving rawhide-nodebug at 3.19, but only for some testing over the android development environment discussed on this list. By Monday, rawhide-nodebug will be synced with rawhide again.
Justin
Justin M. Forbes wrote on 12.02.2015 23:15:
On Thu, 2015-02-12 at 16:31 -0500, Josh Boyer wrote: […]
Looking at the Fedora 22 release schedule, it is most likely that we will wind up shipping with a stable release of the 3.20 series. That means the more testing we get on the kernel now, the better shape it should theoretically be in when we ship. Barring any delays on the Fedora side of things (because those never happen), that will be the plan going forward.
Rawhide and the f22 branch will diverge when the v3.21 window opens up.
If you have any questions/comments, let us know.
At the moment, we are leaving rawhide-nodebug at 3.19, but only for some testing over the android development environment discussed on this list. By Monday, rawhide-nodebug will be synced with rawhide again.
TWIMC: My Kernel vanilla repository as usual will keep 3.19 vanilla in the mainline repo until the merge window closes and then jump to 3.20-rc1; around that time or maybe a week or two later I'll move 3.19 into the stable repos.
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
CU knurd
/me once again things he should create a "Fedora next-stable repo" for those that would like to test 3.19 with all the Fedora-addons now (IOW: before it hits updates-testing in two or three weeks) /me put that thought aside again until he finds more spare time somewhere
Hi Thorsten,
On Fri, 2015-02-13 at 08:28 +0100, Thorsten Leemhuis wrote:
TWIMC: My Kernel vanilla repository as usual will keep 3.19 vanilla in the mainline repo until the merge window closes and then jump to 3.20-rc1; around that time or maybe a week or two later I'll move 3.19 into the stable repos.
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
CU knurd
/me once again things he should create a "Fedora next-stable repo" for those that would like to test 3.19 with all the Fedora-addons now (IOW: before it hits updates-testing in two or three weeks) /me put that thought aside again until he finds more spare time somewhere
This triggered an acute case of TL;DR, but I see only a three interesting routes here.
1) For rawhide: a repository that tracks mainline releases (ie, a repository that is at the latest mainline release for only two weeks, and then starts tracking the latest rc's).
2) For non-rawhide: repositories that track the highest possible stable release (ie, repositories that track the latest mainline release, but track its stable releases until the next mainline release).
3) For non-rawhide: repositories that just rebuild the current kernel package with all non-mainlined patches dropped.
Personally, I have a box that - sort of - does 1 and a box that does 2. I think 1 and 3 look the more interesting routes. Why bother with anything more complicated?
Thanks,
Paul Bolle
kernel@lists.fedoraproject.org
-
Josh Boyer -
Justin Forbes -
Paul Bolle -
Thorsten Leemhuis