From Fedora Project Wiki
(Created page with "This is designed to be a list of ways you can contribute to the Fedora kernel. Some of these items are always available, some are projects that can be removed once completed ...")
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 6: Line 6:
* Run scripts/check-configs.pl and note configs that could possibly be deleted.
* Run scripts/check-configs.pl and note configs that could possibly be deleted.
* The config files are large and enormous. Can they be refactored to be smaller and more managable?
* The config files are large and enormous. Can they be refactored to be smaller and more managable?
** Pull out DT stuff into one common config-devicetree for example(?)
* rodata and page poisoning can now be adjusted by command line options. It might be worth reviewing if these are still appropriate as only debug options
* Review the debug/release options and see if they still make sense or if there are others that should be added

Latest revision as of 00:24, 20 September 2016

This is designed to be a list of ways you can contribute to the Fedora kernel. Some of these items are always available, some are projects that can be removed once completed

  • Report bugs to the upstream kernel community. The kernel is a very big project and it's often necessary to get help directly from the upstream maintainers.
  • Test rawhide kernels. Rawhide is where we try to find the bugs before the kernels hit stable.
  • Run scripts/check-patchlist.sh and note any patches that are unlisted in both the kernel.spec and the patch list. Maintainers try to run this regularly but sometimes they miss things.
  • Run scripts/check-configs.pl and note configs that could possibly be deleted.
  • The config files are large and enormous. Can they be refactored to be smaller and more managable?
    • Pull out DT stuff into one common config-devicetree for example(?)
  • rodata and page poisoning can now be adjusted by command line options. It might be worth reviewing if these are still appropriate as only debug options
  • Review the debug/release options and see if they still make sense or if there are others that should be added