i686 kernel bug priority plan

Josh Boyer jwboyer at fedoraproject.org
Wed Feb 25 13:15:51 UTC 2015


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>


More information about the devel mailing list