Creating a Patch
Contents |
[edit] Identify the need
Before submitting a patch, you have to make sure that it is needed. It will save everybody's time if you avoid writing code that has been already written, or that is not likely to be accepted.
There are basically two cases:
- It's a patch to fix a bug. Yes. It is needed.
- It's a new feature. Then, it may be needed, but the fact that you need it may not be enough. Thus, the following steps are required:
- Search the Internals Mailing List and the Bug Database to see if the same feature request has been already made.
- Discuss your idea on the Internals Mailing list. Make sure that your idea is acceptable, and eventually discuss the technical details of the implementation. They could be useful to create your specs.
- Submit a feature request (bug report with severity 4).
[edit] How to create a patch against the MySQL server source code
- Patches should made against the most current version of the sources.
- Create a local branch of the MySQL Server's Bazaar source tree
- Apply your changes/make the required modifications to your working copy of the source tree
- Test your changes!
- Commit your changes locally
- Create a Bazaar merge directive using bzr send
- The resulting patch file could then be used to discuss your changes with the developers on the Internals Mailing List or for attaching it to your code contribution report
[edit] Submit
Now, in both cases, you have a bug report and a patch, thus, proceed to the following steps:
- Add the required documentation to the bug report. It does not have to be all in one go. You can add the various parts as comments or attach as (plain text) files.
- When all the required docs are added, create the patch in unified or context diff format (please don't submit whole files);
- attach the patch to the bug report;
- (Eventually) Go to the internals mailing list and advertise your patch.
[edit] A patch may not be accepted
Uh? What do you mean, a patch could not be accepted? After all the trouble I took to create it? Yes. It can happen. Not every feature you can think of will be accepted, even if it has all the formal requirements. A few examples of unlikely to be accepted patches:
- replacing the PASSWORD function to use XOR encoding (breaks compatibility, endangers security);
- allowing the server to dump data into existing files (security breech);
- Modifying the query parser to accept misspelled SQL words (breaks standards);
- embedding a LISP interpreter into the server to accept queries in that language (will start flamewar).