You can not select more than 25 topics Topics must start with a chinese character,a letter or number, can include dashes ('-') and can be up to 35 characters long.

CONTRIBUTING.md 2.9 kB

7 years ago
5 years ago
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768
  1. Contributing to Apache Ant
  2. ==========================
  3. You have found a bug or think you know how to code a great feature
  4. that all other people could benefit from? This is great, we'd love to
  5. hear from you.
  6. Ant's primary code repository is the
  7. [git repository at Apache](https://gitbox.apache.org/repos/asf/ant.git)
  8. and we've also got a [github mirror](https://github.com/apache/ant/).
  9. There are two ways you can contribute, you can either use the
  10. "traditional" approach of creating a patch and attaching it to a
  11. Bugzilla issue or you use a github pull request. We do not plan to
  12. use github issues, so if you are reporting a bug, please raise a
  13. [Bugzilla issue](https://issues.apache.org/bugzilla/).
  14. Before reporting a bug, please also review https://ant.apache.org/problems.html
  15. If you're planning to implement a new feature please discuss your
  16. changes on the
  17. [dev list](https://ant.apache.org/mail.html#Developer%20List:%20dev@ant.apache.org)
  18. first. This way you can make sure you're not wasting your time on
  19. something that isn't considered to be in Ant's scope.
  20. Branches
  21. --------
  22. The master branch is where we develop the next release of Ant 1.10.x -
  23. any patch or PR against this branch must be buildable using Java8.
  24. The branch 1.9.x is where we develop the next release of Ant 1.9.x -
  25. any patch or PR against this branch must be buildable using Java5.
  26. Please state clearly whether you are targeting 1.9.x or 1.10.x -
  27. usually we port changes from 1.9.x to 1.10.x but not necessarily the
  28. other way around.
  29. Making Changes
  30. --------------
  31. + Create a topic branch from where you want to base your work (this is
  32. usually the master or the 1.9.x branch, see above).
  33. + Make commits of logical units.
  34. + Respect the original code style:
  35. + Only use spaces for indentation.
  36. + Create minimal diffs - disable on save actions like reformat
  37. source code or organize imports. If you feel the source code
  38. should be reformatted create a separate issue/PR for this change.
  39. + Check for unnecessary whitespace with `git diff --check` before committing.
  40. + Make sure your commit messages are in the proper format. Your commit
  41. message should contain the key of the Bugzilla issue if you created one.
  42. + Make sure you have added the necessary tests for your changes.
  43. + Run all the tests with `./build.sh clean test` to assure nothing
  44. else was accidentally broken.
  45. Submitting Changes
  46. ------------------
  47. + Sign the [Contributor License Agreement][cla] unless your change is
  48. really small or you have already signed one.
  49. + If you want to create a patch for your Bugzilla issue use `git
  50. format-patch` to create it (or a set of patches), this way we can
  51. keep your author information. Attach the patch(es) to the issue.
  52. + Alternatively push your changes to a topic branch in your fork of the repository.
  53. + Submit a pull request to the repository in the apache organization.
  54. [cla]:https://www.apache.org/licenses/#clas