Patch Check List
So, you want to apply a patch? Here are tips, traps, etc. for dealing with patches (in no particular order):
- Get a fresh copy of trunk. Or at least make sure you are up to date and clean your build area. For complex patches, it is recommended you deal with a fresh checkout.
- Look at the patch and see where it is applied. Ideally it is generated from the root, but not everyone does this, especially for contrib areas.
- patch -p 0 -i <path to patch> Throw a --dry-run on there if you want to see what happens w/o screwing up your checkout.
- Did the author write unit tests? Are the unit tests worthwhile?
- How are the benchmark results? contrib/benchmarker may be used to test performance in before/after scenarios.
- Are the licenses correct on newly added files? Has an ASF license been granted?
- Update CHANGES.txt. Give proper credit to the authors.
- Make sure you update JIRA by assigning the issue to you so that others know you are working on it.
- If it is a complex change and you have added to the original author's patch, it is suggested that you create a new patch and attach that to JIRA so that it can be discussed.
- Is it backwards compatible, per BackwardsCompatibility? Does it need to be? That is, are we on a minor revision.
- How's the documentation, esp. the javadocs?
- Before committing, make sure you add any new documents to SVN. Just b/c the patch added them doesn't mean you have.
- Run all unit tests, verify all tests pass.
- Run
ant precommitfrom the top-level directory. - Generate javadocs, verify no javadoc errors/warnings were introduced by the patch.
- Put in a meaningful commit message. Reference the JIRA issue when appropriate. The default commit message in most cases should be: LUCENE-XXXX: some description. Many people and automated systems are setup to pattern match on LUCENE-XXXX: (notice the colon) so please follow that format.
- Remember to update the issue in JIRA when you have completed it.