MySQL Forge

Resources for the MySQL Community

Category: Contributing

Guidelines For Submitting Patches

Contents 1 How to submit a patch 1.1 Identify the need 1.2 Submit 1.3 A patch may not be accepted

[edit] How to submit a patch

[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 bugs system to see if the same feature has been already made.
  • Discuss your idea in the http://lists.mysql.com/internals 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] Submit

Now, in both cases, you have a bug report and a patch, thus, proceed to the following steps:

1. 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.
2. When all the required docs are added, create the patch in unified or context diff format (please don't submit whole files);
3. attach the patch to the bug report;
4. (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).