Changes between Version 7 and Version 8 of TracDev/SubmittingPatches

Timestamp:

Apr 8, 2010, 9:49:19 AM (14 years ago)

Author:

Christian Boos

Comment:

#Submitthepatch hint to #8883 for understanding the reasons it can take a long time to apply a patch

TracDev/SubmittingPatches

@@ -73 +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.
 
+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. 
+
+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.
+
 == What is a good patch? ==
 
@@ -80 +84 @@
    - no spurious changes like whitespace change or other random reformattings
    - 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
-   - strict adherence to the [../CodingStyle coding style]
+   - strict adherence to the CodingStyle
  - maintainability
    - comments for the parts that needs to be commented, no more, no less
-   - add [../UnitTests unit tests] and/or [../FunctionalTests functional tests]
+   - add UnitTests or FunctionalTests
    - make sure existing tests still pass with your change applied
  - and of course, the quality of the code, the pertinence of the fix or the feature is the main criterion