Changes between Version 15 and Version 16 of TracDev/SubmittingPatches
- Timestamp:
- Feb 14, 2015, 11:16:26 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/SubmittingPatches
v15 v16 1 = Submitting Patches =1 = Submitting Patches 2 2 3 Have you made some changes you'd like to submit to Trac? Great! We'd love to see them. However some people who are unfamiliar with the process of submitting changes make it overly complicated for themselves and the developers reviewing the changes. So, in order to make things go smoothly for everyone, here are some guidelines on submitting your changes.3 Have you made some changes you'd like to submit to Trac? Great! We'd love to see them. In order to make things go smoothly for everyone, here are some guidelines on submitting your changes. 4 4 5 == What is a patch? ==5 == What is a patch? 6 6 7 A patch is a single file listing the changes you've made in a format that can be applied with the [http:// www.gnu.org/software/patch/ GNU patch] tool.It will look something like this:7 A patch is a single file listing the changes you've made in a format that can be applied with the [http://savannah.gnu.org/projects/patch/ GNU patch] tool. It will look something like this: 8 8 {{{ 9 9 Index: /branches/0.9-stable/trac/scripts/admin.py … … 27 27 This format is called an "unified diff format". See below how to generate it. 28 28 29 == Getting started ==29 == Getting started 30 30 31 First you'll need to get a copy of the Trac source to make and test your changes. 31 First you'll need to get a copy of the Trac source to make and test your changes. Use [http://subversion.apache.org/ Subversion] to get the source so that you can easily generate your patch. 32 32 33 33 Bug fixes for a current release may be added on the "stable" branch: … … 45 45 Then see [DevelopmentEnvironmentSetup how to setup a development environment]. 46 46 47 == Make some changes ==47 == Make some changes 48 48 49 49 Go ahead and make your changes to the Trac code. 50 50 51 It is a good idea to be familiar with the CodingStyle of the Trac project, so that we won't ask you to rework your changes later on.51 It is a good idea to apply the CodingStyle of the Trac project to your changes, so that we won't ask you to rework your changes later on. 52 52 53 53 Test the changes using [TracTroubleshooting#ModifyingtheCode tracd]. … … 55 55 Ideally, you should write some tests (UnitTests or FunctionalTests) demonstrating the problem you're trying to address - the tests should ''fail'' before the fix and ''pass'' with your changes. Also, by running the tests, you will see if you didn't break anything else with your changes. 56 56 57 A sentence like ''added some more tests - all tests pass'' in your commit message is guaranteed to earn you good points from the maintainers ;-)57 A sentence like ''added some more tests - all tests pass'' in your commit message is guaranteed to earn you points from the maintainers! 58 58 59 == Adding files ==59 == Adding files 60 60 61 Did you create any new files? If you only modified existing Trac files you can skip this.However, if you added any new files be sure to tell Subversion you're adding them:61 Did you create any new files? If you only modified existing Trac files you can skip this. However, if you added any new files be sure to tell Subversion you're adding them: 62 62 63 63 {{{ … … 67 67 The same applies if you use Mercurial, and in Git you'll also have to "add" modified files to the index. 68 68 69 == Make the patch ==69 == Make the patch 70 70 71 71 Simply run: … … 74 74 }}} 75 75 76 This will save your changes to the file "my_patch_file.diff". 76 This will save your changes to the file "my_patch_file.diff". Pick an appropriate filename for the changes you've made. 77 77 78 Note that `svn diff` will generate a diff in the unified format. If for some reason you use the `diff` tool to produce the patch, then please use `diff -u`otherwise the diff won't be an unified diff.78 Note that `svn diff` will generate a diff in the unified format. If you are using the `diff` tool to produce the patch, then please use `diff -u`, otherwise the diff won't be an unified diff. 79 79 80 With Mercurial or Git, make a commit with a detailed log message (the one you'd like to see later on in Trac itself!) and then export it.80 With Mercurial or Git, make a commit with a detailed log message, the one you'd like to see later on in Trac itself! Then export it. 81 81 82 With mercurial, assuming your patch corresponds to the latest commit:82 With Mercurial, assuming your patch corresponds to the latest commit: 83 83 {{{ 84 84 hg export tip > my_patch_file.diff 85 85 }}} 86 86 87 With git, assuming your patch corresponds to the head:87 With Git, assuming your patch corresponds to the head: 88 88 {{{ 89 89 git show > my_patch_file.diff 90 90 }}} 91 91 92 == Submit the patch ==92 == Submit the patch 93 93 94 If there is an existing ticket related to the changes you've made attach your patch file to that ticket. Otherwise please create a new ticket and attach your patch file.Be sure to provide a comment briefly explaining your changes.94 If there is an existing ticket related to the changes you've made, attach your patch file to that ticket. Otherwise please create a new ticket and attach your patch file. Be sure to provide a comment briefly explaining your changes. 95 95 96 You may add the text "[PATCH]" at the beginning of the ticket's "Summary" field as a hint to developers that a p ossible patch has been provided.96 You may add the text "[PATCH]" at the beginning of the ticket's "Summary" field as a hint to developers that a patch has been provided. 97 97 98 98 After that, depending on lots of factors, your patch will be reviewed and eventually integrated. Most probably, you'll be asked to rework your patch a bit, according to the preferences of the Trac maintainers. 99 99 100 If you wonder why your patch didn't get applied as fast as you'd liked to, see for example the case of #8883. Executive summary: while you never have any guarantee that a patch will be integrated, you can influence this outcome by making the developers ''want'' to integrate your patch. For this, read on to the next section. 101 102 == What is a good patch? == 100 == What is a good patch? 103 101 104 102 Now, having written a patch is no guarantee that the change will actually make it into the repository. 105 The patch has to be endorsed by a Trac developer, who will carry the burden to maintain that change over time. So the patch has to be convincing on different accounts:103 The patch has to be endorsed by a Trac developer, who will carry the burden to maintain that change over time. So the patch has to feature the following: 106 104 - clarity 107 105 - no spurious changes like whitespace change or other random reformattings … … 116 114 See for example #8935, #9718. 117 115 118 That can be hard to get right the first time, so you'll certainly get asked to improve your patch. You should be willing to take feedback into account and maybe do a few iterations of the patch , if needed.116 That can be hard to get right the first time, so you'll certainly get asked to improve your patch. You should be willing to take feedback into account and maybe do a few iterations of the patch. 119 117 120 Also useful reading: Mercurial:ContributingChanges#Patch_descriptions. 118 ------ 119 See also: Mercurial:ContributingChanges#Patch_descriptions. 121 120