Hello Fellow Contributors!
Our kernel team has been adrift in bugs roughly forever. The time we spend on triage is time we don't get to spend fixing substantial bugs on hardware lots of people are using, especially new/emergent hardware. We have spoken previously about the difficulty of kernel bug triage as a Fedora effort, and also about future kernel direction at Flock 2014[1].
The Fedora kernel engineers are taking a new approach we think will result in a better kernel overall. We can do more substantial fixes for users, have more interaction upstream, and minimize burnout for the team members. Not coincidentally, we think this will correspondingly strengthen relations between Fedora and kernel communities. We enjoy a healthy relationship there, but we're always looking to do better.
If we pursue the goal of fixing bugs based on impact, we can enjoy these benefits. We see impact as a combination of incidence rate and criticality. But as with all things there are tradeoffs. One of the tradeoffs we foresee is that i686 bugs are unlikely to rise to such a high level of impact. Plenty of bugs are common across architectures, and fixing those bugs will benefit i686 too.
This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started:
* Kernel team wiki page: https://fedoraproject.org/wiki/Kernel -- includes mailing list and IRC information * Bugzilla query: http://tinyurl.com/k6zhz34 -- some example bugs that could use your help
It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal.
Our Fedora kernel engineers are devoted full time to supporting Fedora. Just as any other community members, we have to choose where to spend our cycles because those cycles are finite. With this strategy we think we can make Fedora a better system overall, across all our editions.
Thanks
josh, for the Fedora Kernel Team
[1] http://www.youtube.com/watch?v=F9E0FF4XFDw [2] http://jwboyer.livejournal.com/49909.html
On Wed, Feb 25, 2015 at 2:15 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
Hello Fellow Contributors!
[...] It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal.
Just to make this clear because this has suggestion has been brought up multiple times ... while there might be less interests in running a i686 kernel the story is very different for i686 user space (mostly libraries but also applications like wine) even on a x86_64 host kernel.
So don't draw a line from "no interests in i686 kernel" to "no interesst in the i686 architecture and therefore it should be secondary" .. its not as simple as with a completely isolated architecture like ppc.
On Wed, Feb 25, 2015 at 8:30 AM, drago01 drago01@gmail.com wrote:
On Wed, Feb 25, 2015 at 2:15 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
Hello Fellow Contributors!
[...] It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal.
Just to make this clear because this has suggestion has been brought up multiple times ... while there might be less interests in running a i686 kernel the story is very different for i686 user space (mostly libraries but also applications like wine) even on a x86_64 host kernel.
Yes. The paragraph didn't say kernel and it certainly didn't say that the kernel team would be proposing demotion. It's simply possible that the rest of the project might look at the results that way.
So don't draw a line from "no interests in i686 kernel" to "no interesst in the i686 architecture and therefore it should be secondary" .. its not as simple as with a completely isolated architecture like ppc.
Actually, even your example is flawed. ppc64 ran ppc userspace almost exclusively until the RHEL6 era. It's really kind of the same thing. The major difference being that both of those architectures lacked much in the way of users and support at the time they were demoted.
Anyway, thanks for your comment. It is helpful.
josh
On Wed, Feb 25, 2015 at 08:15:51 -0500, Josh Boyer jwboyer@fedoraproject.org wrote:
This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started:
I try to help with the bugs I run accross. I do bisects to try to find commits and have some interactions with upstream and report back when there are fixes.
I can't afford to replace my old hardware just now. I mostly use PAE kernels, except for a backup laptop that can't do them.
I am not good enough at working with kernel code to be able to do much more than than try to find the commit that triggers a problem and provide various logs to help with debugging.
kernel@lists.fedoraproject.org
-
Bruno Wolff III -
drago01 -
Josh Boyer