Changes between Version 6 and Version 7 of TracDev/SubmittingPatches
- Timestamp:
- Jun 17, 2009, 6:10:09 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/SubmittingPatches
v6 v7 33 33 Bug fixes for a current release may be added on the "stable" branch: 34 34 {{{ 35 svn checkout http://svn.edgewall.org/repos/trac/branches/0.1 0-stable trac-0.10-stable35 svn checkout http://svn.edgewall.org/repos/trac/branches/0.11-stable trac-0.11-stable 36 36 }}} 37 37 … … 41 41 }}} 42 42 43 See [../DevelopmentEnvironmentSetup how to setup a development environment]. 44 43 45 == Make some changes == 44 46 45 Go ahead and make your changes to the Trac code. [TracTroubleshooting#ModifyingtheCode Test them out]. 47 Go ahead and make your changes to the Trac code. 48 Test them using [TracTroubleshooting#ModifyingtheCode tracd]. 46 49 47 50 == Adding files == … … 68 71 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. 69 72 70 Add the text "[PATCH]" at the beginning of the ticket's "Summary" field as a hint to developers that a possible patch has been provided.73 You may add the text "[PATCH]" at the beginning of the ticket's "Summary" field as a hint to developers that a possible patch has been provided. 71 74 72 ---- 73 See also: TracDev 75 == What is a good patch? == 76 77 Now, having written a patch is no guarantee that the change will actually make it into the repository. 78 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: 79 - clarity 80 - no spurious changes like whitespace change or other random reformattings 81 - no unrelated changes; if some refactoring really needs to be done as a preliminary to the actual change, better do that in a separate patch 82 - strict adherence to the [../CodingStyle coding style] 83 - maintainability 84 - comments for the parts that needs to be commented, no more, no less 85 - add [../UnitTests unit tests] and/or [../FunctionalTests functional tests] 86 - make sure existing tests still pass with your change applied 87 - and of course, the quality of the code, the pertinence of the fix or the feature is the main criterion 88 89 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. 90 91 Also useful reading: Mercurial:SuccessfulPatch#How_to_describe_your_successful_patch. 92