2
0

CONTRIBUTING 3.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970
  1. Note: by contributing code to the Redis project in any form, including sending
  2. a pull request via Github, a code fragment or patch via private email or
  3. public discussion groups, you agree to release your code under the terms
  4. of the BSD license that you can find in the COPYING file included in the Redis
  5. source distribution. You will include BSD license in the COPYING file within
  6. each source file that you contribute.
  7. # IMPORTANT: HOW TO USE REDIS GITHUB ISSUES
  8. Github issues SHOULD ONLY BE USED to report bugs, and for DETAILED feature
  9. requests. Everything else belongs to the Redis Google Group:
  10. https://groups.google.com/forum/m/#!forum/Redis-db
  11. PLEASE DO NOT POST GENERAL QUESTIONS that are not about bugs or suspected
  12. bugs in the Github issues system. We'll be very happy to help you and provide
  13. all the support in the mailing list.
  14. There is also an active community of Redis users at Stack Overflow:
  15. http://stackoverflow.com/questions/tagged/redis
  16. # Reporting Security Bugs
  17. *If you are reporting a security bug*, please contact the core team privately
  18. by emailing redis@redis.io. Your report will be acknowledged by a core team
  19. member and once the report has been reviewed you will receive a more detailed
  20. response including next steps.
  21. If you do not receive a reply you can escalate to the Redis Google Group,
  22. linked above. Because this group is a public space please do not disclose the
  23. issue in detail, only say that you are trying to reach the core team for a
  24. security issue.
  25. Redis follows a responsible disclosure process:
  26. 1. Reports are reviewed and analyzed privately
  27. 2. Patches are prepared for supported versions of Redis
  28. 3. Vendor lists are notified with an embargo date to reduce the public impact
  29. 4. We push a fix release and your bug can be posted publicly with credit in
  30. release notes and the version history (and our thanks!)
  31. # How to provide a patch for a new feature
  32. 1. If it is a major feature or a semantical change, please don't start coding
  33. straight away: if your feature is not a conceptual fit you'll lose a lot of
  34. time writing the code without any reason. Start by posting in the mailing list
  35. and creating an issue at Github with the description of, exactly, what you want
  36. to accomplish and why. Use cases are important for features to be accepted.
  37. Here you'll see if there is consensus about your idea.
  38. 2. If in step 1 you get an acknowledgment from the project leaders, use the
  39. following procedure to submit a patch:
  40. a. Fork Redis on github ( http://help.github.com/fork-a-repo/ )
  41. b. Create a topic branch (git checkout -b my_branch)
  42. c. Push to your branch (git push origin my_branch)
  43. d. Initiate a pull request on github ( https://help.github.com/articles/creating-a-pull-request/ )
  44. e. Done :)
  45. 3. Keep in mind that we are very overloaded, so issues and PRs sometimes wait
  46. for a *very* long time. However this is not lack of interest, as the project
  47. gets more and more users, we find ourselves in a constant need to prioritize
  48. certain issues/PRs over others. If you think your issue/PR is very important
  49. try to popularize it, have other users commenting and sharing their point of
  50. view and so forth. This helps.
  51. 4. For minor fixes just open a pull request on Github.
  52. Thanks!