contribute.txt 4.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125
  1. // -*- mode:doc; -*-
  2. Contibuting to Buildroot
  3. ========================
  4. If you want to contribute to Buildroot, you will need a git view of
  5. the project. Refer to xref:getting-buildroot[] to get it.
  6. Currently, the mailing list is the central place for contribution.
  7. If you have not already subscribed to it, then refer to
  8. xref:mailing-list-subscribe[].
  9. Recently, a web interface is also used to manage patches sent to the
  10. mailing list, see xref:patchwork[].
  11. [NOTE]
  12. _Please, do not attach patches to bugs, send them to the mailing list
  13. instead_ (see xref:submitting-patches[]).
  14. [[submitting-patches]]
  15. Submitting patches
  16. ------------------
  17. When your changes are done, and committed in your local git view,
  18. _rebase_ your development branch on top of the upstream tree before
  19. generating the patch set. To do so, run:
  20. ---------------------
  21. $ git fetch --all --tags
  22. $ git rebase origin/master
  23. ---------------------
  24. Here, you are ready to generate then submit your patch set.
  25. To generate it, run:
  26. ---------------------
  27. $ git format-patch -M -n -s -o outgoing origin/master
  28. ---------------------
  29. This will generate patch files in the +outgoing+ subdirectory,
  30. automatically adding the +signed-off-by+ line.
  31. If you want to present the whole patch set in a separate mail, add
  32. +--cover-letter+ to the previous command line (+man git-format-patch+
  33. for further information).
  34. Once patch files are generated, you can review/edit the commit message
  35. before submitting them using your favorite text editor.
  36. Lastly, send/submit your patch set to the Buildroot mailing list:
  37. ---------------------
  38. $ git send-email --to buildroot@busybox.net outgoing/*
  39. ---------------------
  40. Note that +git+ should be configured to use your mail account.
  41. To configure +git+, see +man git-send-email+ or google it.
  42. Make sure posted *patches are not line-wrapped*, otherwise they cannot
  43. easily be applied. In such a case, fix your e-mail client, or better,
  44. use +git send-email+ to send your patches.
  45. Reviewing/Testing patches
  46. -------------------------
  47. In the review process, do not hesitate to respond to patch submissions
  48. for remarks, suggestions or anything that will help everyone to
  49. understand the patches and make them better.
  50. Some tags are used to help following the state of any patch posted on
  51. the mailing-list:
  52. Acked-by:: Indicates that the patch can be committed.
  53. Tested-by:: Indicates that the patch has been tested. It is useful
  54. but not necessary to add a comment about what has been tested.
  55. Autobuild
  56. ---------
  57. The Buildroot community is currently setting up automatic builds in
  58. order to test more and more configurations. All build results are
  59. available at http://autobuild.buildroot.org[]
  60. A good way to contribute is by fixing broken builds.
  61. In the commit message of a patch fixing an _autobuild_, add a
  62. reference to the _build result directory_ (the +dir+ link in the _data
  63. column_):
  64. ---------------------
  65. Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
  66. ---------------------
  67. [[reporting-bugs]]
  68. Reporting issues/bugs, get help
  69. -------------------------------
  70. Before reporting any issue, please check
  71. xref:mailing-list-subscribe[the mailing list archive] in case someone has
  72. already reported and fixed a similar problem.
  73. However you choose to report bugs or get help,
  74. xref:bugtracker[opening a bug] or
  75. xref:mailing-list-subscribe[send a mail to the mailing list], there are
  76. a number of details to provide in order to help people reproduce and
  77. find a solution to the issue.
  78. Try to think as if you were trying to help someone else; in
  79. that case, what would you need?
  80. Here is a short list of details to provide in such case:
  81. * host machine (OS/release)
  82. * version of Buildroot
  83. * target for which the build fails
  84. * package(s) which the build fails
  85. * the command that fails and its output
  86. * any information you think that may be relevant
  87. Additionnally, your can add the +.config+ file.
  88. If some of these details are too large, do not hesitate to use a
  89. pastebin service (see http://www.similarsitesearch.com/alternatives-to/pastebin.com[]).