It's been a while since we gave an overview of the kernel plans for Fedora, so I thought I'd send a brief update on what we're doing, where we're headed, and why.
Rawhide:
Rawhide is basically trucking along as it normally does, tracking the latest upstream Linus tree. This will continue for the forseeable future, so there really are no surprises here. At the moment, it is at 3.1-rc4 and overall seems fairly stable. There is an ext4 lockdep trace that quite a few people have hit, but a fix has been posted upstream and should be included in the next build.
F16:
The F16 Alpha released with the first stable release of the 3.0 kernel, but it has since transitioned to the 3.1 pre-release kernels. The plan for the final release is to ship 3.1 final (or the latest stable release of it), but there wasn't time to get that into the Alpha. Currently, we're at 3.1-rc4, which means we're synced with rawhide. This will continue until 3.1 final is released.
The F16 kernels also still have the debug options enabled. We've found that testing of the rawhide kernel is somewhat limited, and we don't get many reports aginst that. Most of the lockdep issues or other bugs found in the 3.1 kernel so far have come from people running F16, so this is paying off in terms of getting the kernel debugged and fixed before the final release. It does have the side-effect of introducing a performance penalty in some cases, but we'd rather get the bugs fixed first. The debug options will be disabled and we'll move to a release kernel once 3.1 final is released and built.
F15:
F15 has now moved to the 2.6.40 kernel. If you haven't been paying attention lately, you'll probably be saying "wait... there is no 2.6.40 upstream" and you would be right. So Fedora's 2.6.40 is really the 3.0 upstream kernel, "rebranded" to follow the 2.6.x numbering scheme. This was done to avoid userspace incompatibilities with the 3.x numbering scheme for packages that were either tightly coupled to kernel version and/or, uh, doing things a bit wrongly. Most of those packages have been fixed in f16 at this point.
We're at the equivalent of the 3.0.4 stable release in updates-testing and that should be moving to updates relatively soon.
F14:
Sigh. F14 is still on the 2.6.35.x longterm kernel, currently at 2.6.35.14. This is both good and bad. Good in that it's the oldest supported release, and we've got somewhat of a known quantity with this kernel at this point. Bad because the upstream stable branch is updated fairly infrequently and seems to be somewhat in zombie state.
We've spent the last week or so trying to plow through the F14 bugzilla backlog. This has sort of paid off by clearing out a bunch of stale bugs, duplicates, and things that were fixed and never closed. At the moment, we're under 300 bugs which isn't great but is much improved overall.
Going forward, we're at sort of an impasse. The two most likely options are staying on 2.6.35.x, or moving to 2.6.40 as F15 did. We know that there are areas where 2.6.35.x is just broken or insufficient (USB 3 support, various suspend/resume issues) that might be improved in 2.6.40 but that comes with the risk of hitting userspace interaction bugs. We're keeping an eye on this and trying to come up with the best all around decision, but it is not an easy choice. In the meantime, if you are having lots of issues with F14, we strongly you to upgrade to F15.
(Yes, we are aware of the fact that some people want to stick with F14 to avoid Gnome3. That's outside of the scope of the kernel and we really don't want to discuss it here.)
So there's a brief overview of the kernel happenings going on in Fedora. If you have questions, feel free to shoot an email to the fedora kernel list!
josh
On 09/01/2011 09:44 AM, Josh Boyer wrote:
(Yes, we are aware of the fact that some people want to stick with F14 to avoid Gnome3. That's outside of the scope of the kernel and we really don't want to discuss it here.)
Thanks for the update and thoughts.
I'd just add that the fear of gnome-3 is, or perhaps should be, less of an issue. We have KDE, LXDE, XFCE etc - everyone I know has dropped Gnome and moved to something else - and this only impacts laptop/desktop setups. F15 on the desktop/laptop is moving ahead nicely I think.
Rather, I think it is the fear of systemd not yet being reliable (on F15 anyway), especially for network coupled services being started at boot without human interaction, that is likely the bigger concern. This is slowing F15 adoption on non-desktop/server type setups.
Testing systemd on laptop/desktop - gives folks the opportunity to explore how well systemd is working and to enjoy the newer kernels.
Since we're not supporting upstart in F15, it does make sense to try and move 2.6.40 onto F14 to hold folks until they get more comfortable (presumably F16) that systemd will be trustworthy for standalone boxes.
It seems feasable so to me, but does require updates to mdadm, module-init-tools, procps and Mesa (and maybe more). If I remember rightly, I needed those to test newer kernel on F14.
Also, 2.6.40.4 is running beautifully for me on F15 - auto sched is rather brilliant - esp when compiling -j8 (or whatever) .. thank you!
gene
On Thu, Sep 01, 2011 at 12:01:13PM -0400, Genes MailLists wrote:
On 09/01/2011 09:44 AM, Josh Boyer wrote:
(Yes, we are aware of the fact that some people want to stick with F14 to avoid Gnome3. That's outside of the scope of the kernel and we really don't want to discuss it here.)
Rather, I think it is the fear of systemd not yet being reliable (on F15 anyway), especially for network coupled services being started at boot without human interaction, that is likely the bigger concern. This is slowing F15 adoption on non-desktop/server type setups.
Testing systemd on laptop/desktop - gives folks the opportunity to explore how well systemd is working and to enjoy the newer kernels.
Since we're not supporting upstart in F15, it does make sense to try and move 2.6.40 onto F14 to hold folks until they get more comfortable (presumably F16) that systemd will be trustworthy for standalone boxes.
systemd is supported on F15. There was an update released for it yesterday.
Anyway, that's beyond the scope of the kernel. There's nothing we can do about whatever reason people have for sticking with F14, unless that reason is something broken in a newer kernel (which they probably wouldn't know if they're sticking with F14, but I digress.)
It seems feasable so to me, but does require updates to mdadm, module-init-tools, procps and Mesa (and maybe more). If I remember rightly, I needed those to test newer kernel on F14.
And microcode_ctl. Those are the minimums to be safe, although the whole point of calling it 2.6.40 was to avoid the versioning incompatibilities.
I'm also concerned about the older xorg stack with the newer drivers, but that might just be my unfamiliarity with how intertwined they are.
Also, 2.6.40.4 is running beautifully for me on F15 - auto sched is rather brilliant - esp when compiling -j8 (or whatever) .. thank you!
Great, glad it's working well for you.
josh
On Thu, Sep 01, 2011 at 09:44:04 -0400, Josh Boyer jwboyer@redhat.com wrote:
Rawhide:
Rawhide is basically trucking along as it normally does, tracking the latest upstream Linus tree. This will continue for the forseeable future, so there really are no surprises here. At the moment, it is at 3.1-rc4 and overall seems fairly stable. There is an ext4 lockdep trace that quite a few people have hit, but a fix has been posted upstream and should be included in the next build.
I have a bug report for crashes related to software raid that is happening with 3.1 kernels in both F16 and F17. Neil Brown has started looking at it but was waiting for a more complete traceback which I just got to the bug report this morning. (netconsole was very helpful for this.)
"JB" == Josh Boyer jwboyer@redhat.com writes:
JB> F14: [...] JB> The two most likely options are staying on 2.6.35.x, or moving to JB> 2.6.40 as F15 did.
Has anyone made 2.6.40 packages install on F14? Unfortunately the F15 kernel package needs some other stuff, and due to all of the systemd changes I'm not sure it would boot OK.
I would happily deploy a 2.6.40 on my remaining F14 machines even if I had to pull it from an external repo.
- J<
On Thu, Sep 01, 2011 at 12:22:07PM -0500, Jason L Tibbitts III wrote:
"JB" == Josh Boyer jwboyer@redhat.com writes:
JB> F14: [...] JB> The two most likely options are staying on 2.6.35.x, or moving to JB> 2.6.40 as F15 did.
Has anyone made 2.6.40 packages install on F14? Unfortunately the F15 kernel package needs some other stuff, and due to all of the systemd changes I'm not sure it would boot OK.
No. And I wouldn't recommend force installing the F15 versions either. If (and it's a big if) we move F14 to 2.6.40, we need to update a number of userspace packages first, including microcode_ctl so people with various AMD systems can actually boot...
I would happily deploy a 2.6.40 on my remaining F14 machines even if I had to pull it from an external repo.
We need to discuss this a bit more, but we could potentially setup a koper with the various bits.
josh
On Thu, Sep 01, 2011 at 01:59:59PM -0400, Josh Boyer wrote:
On Thu, Sep 01, 2011 at 12:22:07PM -0500, Jason L Tibbitts III wrote:
> "JB" == Josh Boyer jwboyer@redhat.com writes:
JB> F14: [...] JB> The two most likely options are staying on 2.6.35.x, or moving to JB> 2.6.40 as F15 did.
Has anyone made 2.6.40 packages install on F14? Unfortunately the F15 kernel package needs some other stuff, and due to all of the systemd changes I'm not sure it would boot OK.
No. And I wouldn't recommend force installing the F15 versions either. If (and it's a big if) we move F14 to 2.6.40, we need to update a number of userspace packages first, including microcode_ctl so people with various AMD systems can actually boot...
I would happily deploy a 2.6.40 on my remaining F14 machines even if I had to pull it from an external repo.
We need to discuss this a bit more, but we could potentially setup a koper with the various bits.
We thought this over a bit last friday afternoon and I thought I would reply so that everyone knew what the decision for F14 is.
The creation of a separate repo that contains 2.6.40 for F14 is certainly possible, but at the moment we aren't sure it's worth doing. The major concern is that it becomes a timesink in both creation and support. We know of a certain set of userspace that needs to be updated to work with 2.6.40, but that isn't an all inclusive list.
Assuming F16 is released in November, F14 will go EOL in December which leaves just 3-4 months of support remaining. The frequency of new bug reports on F14 has been fairly low over the past month or so, likely due to people moving to F15 and the 2.6.35.x kernel being a known quantity.
So for F14 we are going to remain on 2.6.35.x until EOL and focus mostly on security fixes and low hanging fruit bug fixes. Those with major issues will be encouraged to upgrade to F15.
Going forward, we're going to get back into rebasing more frequently during a release and that should help avoid being stuck on older kernels.
josh
Has anyone made 2.6.40 packages install on F14?
I have successfully compiled and installed 2.6.40.3-2 on FC13. I don't use systemd either. Obviously, I've had a few upgrades to do, but those were compiled in from source rpms using dependencies based on what I have in FC13. I also upgraded the entire xorg/gnome stack with what is currently on FC14 - 2.32 if I am not mistaken (and no, I am *not* moving to gnome 3 before anyone asks).
The same kernel was compiled for a different arch on the same machine (I am on x86_64, the target I used was i686 - PII) and used for building a distribution images with the help of kickstart - again, that was completed with no issues.
I have been using the 2.6.40 branch of the kernel for quite a while now (having been on 2.6.38 previously - all on FC13) and apart from a few problems with nouveau, which I am pleased to report have now been cleared - more or less - I have had no issues with this kernel at all.
On Thu, 2011-09-01 at 12:22 -0500, Jason L Tibbitts III wrote:
Has anyone made 2.6.40 packages install on F14? Unfortunately the F15 kernel package needs some other stuff, and due to all of the systemd changes I'm not sure it would boot OK.
I would happily deploy a 2.6.40 on my remaining F14 machines even if I had to pull it from an external repo.
v2.6.40 and v3.0 being actually the same thing, I can tell that about a week ago I wrote this to this list:
A related anecdote: I'm currently running a (Rawhide derived, locally rebuilt) v3.0.x kernel package on F14 (this is a laptop with a rather boring setup). To get that package installed I also backported (ie, rebuilt locally) mdadm-3.2.1-5 and module-init-tools-3.16-2. No obvious breakage, at least not yet...
But the obvious disclaimer for stuff like this is: if it breaks, you get to keep the pieces.
I still have not encountered any obvious problems due to some v3.0 and F14 mismatch.
There are some downsides to this solution (eg, it's a lot of work). Besides, I'm pretty sure it's not worth the effort (even if using prebuilt packages) for those few months of life still left in F14.
Paul Bolle
Something that Josh didn't mention that should probably be brought up is one of the changes we've made internally in the fedora kernel team.
Until recently, things were generally a free-for-all, where we'd all be committing to all branches, with no specific focus. It worked for the most part for all the previous years, but there have been occasions where we've had people duplicating work, and treading on toes by committing to the same branches etc.
Going forward, we've decided that each month, each of us will be responsible for a specific release. As well as having a focused goal to be working on for the month, it hopefully allows us all to not feel quite so buried by looking at the big picture all the time.
You can see who is the 'go to guy' for a specific release at any time by reading https://fedoraproject.org/wiki/Kernel
For the most part, you'll only need to know this for mailing patches. All other discussion should be happening either here, or upstream.
Dave
Hi!
On 01.09.2011 15:44, Josh Boyer wrote:
It's been a while since we gave an overview of the kernel plans for Fedora, so I thought I'd send a brief update on what we're doing, where we're headed, and why. [...] So there's a brief overview of the kernel happenings going on in Fedora. If you have questions, feel free to shoot an email to the fedora kernel list!
A few questions spring to my mind:
* there were a few attempts and discussions to ship vanilla kernels in separate repos or even directly in the Fedora repositories. I assume you guys (or anybody else on this list) don't have time or interest in renew those efforts? I sometimes think they might be handy to have, as it would make statements like "please try the latest vanilla rpm; if it does not work there try to bug upstream about it directly, as we in Fedora likely won't come down to fix this individual bug, because it's a very specific problem that bugs only very few people" possible.
* how long will this continue to be a draft? http://fedoraproject.org/wiki/KernelStagingPolicy And does it really has to be that strict?
* Will updates like the one to 3.0/2.6.40 in F15 be considered normal practice again for the future? Updates to latest kernel versions in the latest Fedora release where nothing unusual in the past, but it always bugged me that they happened to be so unpredictable (got way worse in the past year afaics)t
* if updates to latest kernel versions become normal again, wouldn't it be a good idea to set up a repo that contains the latest rc kernels for the latest Fedora release? Maybe a few people that (for example) run F15 now might be interested interested and improving the 3.1/2.6.41 packages before they hit updates-testing once 3.1 got released.
CU knurd
P.S.: Yes, I might be willing to help with some of the things I'm asking for here as time permits; the latter is a problem right now that frustrates me a bit :-/
On Thu, Sep 01, 2011 at 10:33:34PM +0200, Thorsten Leemhuis wrote:
Hi!
On 01.09.2011 15:44, Josh Boyer wrote:
It's been a while since we gave an overview of the kernel plans for Fedora, so I thought I'd send a brief update on what we're doing, where we're headed, and why. [...] So there's a brief overview of the kernel happenings going on in Fedora. If you have questions, feel free to shoot an email to the fedora kernel list!
A few questions spring to my mind:
I'll give my personal answers. If Dave or Chuck disagree, I'm sure they''ll do so publicly :).
- there were a few attempts and discussions to ship vanilla kernels in
separate repos or even directly in the Fedora repositories. I assume you guys (or anybody else on this list) don't have time or interest in renew those efforts? I sometimes think they might be handy to have, as it would make statements like "please try the latest vanilla rpm; if it does not work there try to bug upstream about it directly, as we in Fedora likely won't come down to fix this individual bug, because it's a very specific problem that bugs only very few people" possible.
I was doing that a long time ago and uploading them to my fedorapeople account. I don't have a ton of time to do that right now, but it might be worthwhile for someone to do builds of major releases (3.0, 3.1) for vanilla to have them handy. Volunteers for that gladly accepted.
I will point out though that we continue to try and avoid deviation from upstream as much as possible. Aside from fixes, there are really only a small handful of add-on patches in the Fedora kernels. utrace and the i686 nx/execshield are the biggest and hopefully those also sort of go away. Hopefully the _need_ for vanilla kernels is fairly small.
- how long will this continue to be a draft?
No longer. It's been the defacto policy for a while now. Draft is removed.
And does it really has to be that strict?
Yes. Staging drivers can be a huge timesink, particularly when users think they are getting something that will JUST WORK for their hardware and then it turns out to be a steaming pile of crap.
- Will updates like the one to 3.0/2.6.40 in F15 be considered normal
practice again for the future? Updates to latest kernel versions in the latest Fedora release where nothing unusual in the past, but it always bugged me that they happened to be so unpredictable (got way worse in the past year afaics)t
I'm guessing it will be normal practice, yes. Being somewhat new here, I'm not sure why it fell out of practice. Updating to the latest has a couple of factors involved with it, so it's not always a simple decision.
I hope going forward that we're a bit more communicative with our plans. That's kind of why I sent my original email today.
- if updates to latest kernel versions become normal again, wouldn't it
be a good idea to set up a repo that contains the latest rc kernels for the latest Fedora release? Maybe a few people that (for example) run F15 now might be interested interested and improving the 3.1/2.6.41 packages before they hit updates-testing once 3.1 got released.
There's a few downsides to doing that:
1) Time
2) Multiplying the kernels out there
3) Potentially pulling testers off of Branched/Rawhide just because their only interested in the kernel. We have a hard enough time getting people to test Branched/Rawhide as it is, so personally I'm not keen on making that even more prevelant.
4) Going with 3 above, we tend to wait until a kernel is somewhat 'proven' in the newest release before pulling it into something stable.
josh
On Thu, Sep 01, 2011 at 05:34:42PM -0400, Josh Boyer wrote:
A few questions spring to my mind:
I'll give my personal answers. If Dave or Chuck disagree, I'm sure they''ll do so publicly :).
Spot on as far as I'm concerned.
I will point out though that we continue to try and avoid deviation from upstream as much as possible. Aside from fixes, there are really only a small handful of add-on patches in the Fedora kernels. utrace and the i686 nx/execshield are the biggest and hopefully those also sort of go away. Hopefully the _need_ for vanilla kernels is fairly small.
Some of the lower hanging fruit got pushed again this cycle. When we move to 3.2, the fedora specific patches should be the smallest they've been in a long time.
(related: I'm tempted to remove all the vanilla stuff from the spec just to reduce some of the noise in there. Any objections ? I think Roland was the only person who ever really used it)
And does it really has to be that strict?
Yes. Staging drivers can be a huge timesink, particularly when users think they are getting something that will JUST WORK for their hardware and then it turns out to be a steaming pile of crap.
Something worth pointing out, is that if there's enough demand from users for a specific driver to be cleaned up so we can support it, in some cases we may be in a position where we can task someone with that. We used to do a lot more of this sort of thing in the Red Hat Linux days than we have done in Fedora.
- Will updates like the one to 3.0/2.6.40 in F15 be considered normal
practice again for the future? Updates to latest kernel versions in the latest Fedora release where nothing unusual in the past, but it always bugged me that they happened to be so unpredictable (got way worse in the past year afaics)t
I'm guessing it will be normal practice, yes. Being somewhat new here, I'm not sure why it fell out of practice. Updating to the latest has a couple of factors involved with it, so it's not always a simple decision.
I think f14 was the tail end of the "don't update the kernel because X will crap itself" problems. (Probably even sooner actually, but paranoia kept us on .35 forever).
Going forward, I think it's pretty clear to see that it's worth continually moving just like we used to. Yes we introduce new bugs every time, but we close out a lot more. The .40 update closed over a hundred bugs with little or no actual intervention on our part. (And probably more that just haven't retested/updated bz yet). Additionally being able to bug upstream with bugs on recent codebases instead of something from a year ago is invaluable.
Dave
I think f14 was the tail end of the "don't update the kernel because X will crap itself" problems. (Probably even sooner actually, but paranoia kept us on .35 forever).
That should have been F13 :), I thought we had sort of lapsed into any longterm kernel upstream we'd just stay on it as it had claimed security fixes coming through. (of course for .35 its mostly lies).
Dave.
On Fri, 2 Sep 2011 02:41:18 -0400 (EDT) David Airlie airlied@redhat.com wrote:
I think f14 was the tail end of the "don't update the kernel because X will crap itself" problems. (Probably even sooner actually, but paranoia kept us on .35 forever).
That should have been F13 :), I thought we had sort of lapsed into any longterm kernel upstream we'd just stay on it as it had claimed security fixes coming through. (of course for .35 its mostly lies).
2.6.35.14 caught up on the security fixes pretty well, but it took 3-5 months from when some issues were first known. It is still a couple of months behind even today, with just a few older problems still unfixed.
On Thu, 2011-09-01 at 18:24 -0400, Dave Jones wrote:
(related: I'm tempted to remove all the vanilla stuff from the spec just to reduce some of the noise in there. Any objections ? I think Roland was the only person who ever really used it)
Well, I actually used it for a few months. But since I had to edit the kernel.spec anyway (ie, add a local ID, update the changelog, etc.) I just added a "--without patches" switch to the kernel.spec in my local copy of the Fedora kernel.git repo.
So I wouldn't mind dropping the vanilla stuff, as long as it remains possible (ie, without having to jump through hoops) to rebuilt locally while using only vanilla sources.
Paul Bolle
Hi!
Dave Jones wrote on 02.09.2011 00:24:
On Thu, Sep 01, 2011 at 05:34:42PM -0400, Josh Boyer wrote:
I will point out though that we continue to try and avoid deviation from upstream as much as possible. Aside from fixes, there are really only a small handful of add-on patches in the Fedora kernels. utrace and the i686 nx/execshield are the biggest and hopefully those also sort of go away. Hopefully the _need_ for vanilla kernels is fairly small.
Some of the lower hanging fruit got pushed again this cycle. When we move to 3.2, the fedora specific patches should be the smallest they've been in a long time.
(related: I'm tempted to remove all the vanilla stuff from the spec just to reduce some of the noise in there. Any objections ? I think Roland was the only person who ever really used it)
Well, I actually really consider to offer prebuild vanilla kernels for fedora in a repo (but until End of October I won't have time to start on this) and the vanilla conditionals that are in the spec file right now would make my life a lot easier afaics.
And does it really has to be that strict?
Yes. Staging drivers can be a huge timesink, particularly when users think they are getting something that will JUST WORK for their hardware and then it turns out to be a steaming pile of crap.
I understand that and agree for most of the staging drivers. But:
Something worth pointing out, is that if there's enough demand from users for a specific driver to be cleaned up so we can support it, in some cases we may be in a position where we can task someone with that. We used to do a lot more of this sort of thing in the Red Hat Linux days than we have done in Fedora.
Things like that is basically what I meant when I asked "does it really has to be that strict?".
Another reason: The Hyper-V drivers in staging are still not perfect afaics, but MS seems to be taking the job of improving them seriously for some months now. Sure, there still plenty that can go wrong, but in the current situation I'd say the benefits of shipping the drivers (and thus making it easier for people to test) might be worth ignoring the downsides.
- Will updates like the one to 3.0/2.6.40 in F15 be considered normal
practice again for the future? Updates to latest kernel versions in the latest Fedora release where nothing unusual in the past, but it always bugged me that they happened to be so unpredictable (got way worse in the past year afaics)t
I'm guessing it will be normal practice, yes. Being somewhat new here, I'm not sure why it fell out of practice. Updating to the latest has a couple of factors involved with it, so it's not always a simple decision.
I think f14 was the tail end of the "don't update the kernel because X will crap itself" problems. (Probably even sooner actually, but paranoia kept us on .35 forever).
Yeah, understood, Hopefully we can avoid similar problems in the future right from the start.
Going forward, I think it's pretty clear to see that it's worth continually moving just like we used to. Yes we introduce new bugs every time, but we close out a lot more. The .40 update closed over a hundred bugs with little or no actual intervention on our part. (And probably more that just haven't retested/updated bz yet). Additionally being able to bug upstream with bugs on recent codebases instead of something from a year ago is invaluable.
Sounds really good, I'm all for it :-)
CU knurd
On Fri, 2011-09-02 at 12:55 +0200, Thorsten Leemhuis wrote:
Dave Jones wrote on 02.09.2011 00:24:
(related: I'm tempted to remove all the vanilla stuff from the spec just to reduce some of the noise in there. Any objections ? I think Roland was the only person who ever really used it)
Well, I actually really consider to offer prebuild vanilla kernels for fedora in a repo (but until End of October I won't have time to start on this) and the vanilla conditionals that are in the spec file right now would make my life a lot easier afaics.
One of the problems I seem to remember is that the packages will be named kernel-vanilla* (instead of just kernel*). And once one has only kernel-vanilla* packages installed (and no kernel* packages) some other packages (I think from the *-devel variety) can complain upon install or update.
Paul Bolle
Hi!
Josh Boyer wrote on 01.09.2011 23:34:
On Thu, Sep 01, 2011 at 10:33:34PM +0200, Thorsten Leemhuis wrote:
On 01.09.2011 15:44, Josh Boyer wrote:
It's been a while since we gave an overview of the kernel plans for Fedora, so I thought I'd send a brief update on what we're doing, where we're headed, and why. [...] So there's a brief overview of the kernel happenings going on in Fedora. If you have questions, feel free to shoot an email to the fedora kernel list!
A few questions spring to my mind:
I'll give my personal answers. If Dave or Chuck disagree, I'm sure they''ll do so publicly :).
Thanks for your answers!
- there were a few attempts and discussions to ship vanilla kernels in
separate repos or even directly in the Fedora repositories. I assume you guys (or anybody else on this list) don't have time or interest in renew those efforts? I sometimes think they might be handy to have, as it would make statements like "please try the latest vanilla rpm; if it does not work there try to bug upstream about it directly, as we in Fedora likely won't come down to fix this individual bug, because it's a very specific problem that bugs only very few people" possible.
I was doing that a long time ago and uploading them to my fedorapeople account. I don't have a ton of time to do that right now, but it might be worthwhile for someone to do builds of major releases (3.0, 3.1) for vanilla to have them handy. Volunteers for that gladly accepted.
I'll try to find time for that.
I will point out though that we continue to try and avoid deviation from upstream as much as possible. Aside from fixes, there are really only a small handful of add-on patches in the Fedora kernels. utrace and the i686 nx/execshield are the biggest and hopefully those also sort of go away. Hopefully the _need_ for vanilla kernels is fairly small.
Yeah, understood and known, but I still have the feeling a lot of upstream maintainers will tell people to try vanilla kernels before they start listing at bug reports at all (and utrace and the nx stuff iirc in the past were responsible for some odd bugs in other areas but [maybe I'm wrong with that], so that demand is not completely unreasonable afaics)
- how long will this continue to be a draft?
No longer. It's been the defacto policy for a while now. Draft is removed.
And does it really has to be that strict?
Yes. Staging drivers can be a huge timesink, particularly when users think they are getting something that will JUST WORK for their hardware and then it turns out to be a steaming pile of crap.
/me will write something in the reply to davej's mail
- Will updates like the one to 3.0/2.6.40 in F15 be considered normal
practice again for the future? Updates to latest kernel versions in the latest Fedora release where nothing unusual in the past, but it always bugged me that they happened to be so unpredictable (got way worse in the past year afaics)t
I'm guessing it will be normal practice, yes.
+1
[...]
- if updates to latest kernel versions become normal again, wouldn't it
be a good idea to set up a repo that contains the latest rc kernels for the latest Fedora release? Maybe a few people that (for example) run F15 now might be interested interested and improving the 3.1/2.6.41 packages before they hit updates-testing once 3.1 got released.
There's a few downsides to doing that:
Time
Multiplying the kernels out there
Potentially pulling testers off of Branched/Rawhide just because
their only interested in the kernel. We have a hard enough time getting people to test Branched/Rawhide as it is, so personally I'm not keen on making that even more prevelant.
- Going with 3 above, we tend to wait until a kernel is somewhat
'proven' in the newest release before pulling it into something stable.
But I assume you wouldn't mind to much if someone would knowingly ignore 2 and 3 and set such a repo up somewhere to see if people would use it?
CU knurd
On Fri, Sep 02, 2011 at 12:55:16 +0200, Thorsten Leemhuis fedora@leemhuis.info wrote:
Yeah, understood and known, but I still have the feeling a lot of upstream maintainers will tell people to try vanilla kernels before they start listing at bug reports at all (and utrace and the nx stuff iirc in the past were responsible for some odd bugs in other areas but [maybe I'm wrong with that], so that demand is not completely unreasonable afaics)
I don't see that. (I had an upstream bug for 3.0 and now another one for 3.1.) There is even a checkbox for Fedora kernels in the upstream bug system. So I think they are OK with with them.
Josh Boyer wrote: : It's been a while since we gave an overview of the kernel plans for : Fedora, so I thought I'd send a brief update on what we're doing, where : we're headed, and why.
Hello,
thanks for the update!
: (Yes, we are aware of the fact that some people want to stick with F14 : to avoid Gnome3. That's outside of the scope of the kernel and we : really don't want to discuss it here.)
I don't think GNOME 3 is a problem. People I know are moving away to other DEs (I have moved to XFCE, and it feels pretty similar to GNOME 2).
For me the blocker for upgrading the kernel on my primary workstation is the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=719260
I should probably move it upstream or whatever.
-Yenya
kernel@lists.fedoraproject.org
-
Bruno Wolff III -
Chuck Ebbert -
Dave Jones -
David Airlie -
Genes MailLists -
Jan Kasprzak -
Jason L Tibbitts III -
Josh Boyer -
Mr Dash Four -
Paul Bolle -
Thorsten Leemhuis