Guidance for Porting
Every line of patch must be understood and justifiable. You should understand every aspect of your patch, and be able to defend it online. If something doesn't make sense in the package you are trying to port, then this may be a bug that needs to be fixed. Do not copy code sections blindly (cargo-culting).
Other architectures should not be broken. Your patches should not break existing architecture support for the package. You must test the package with another architecture as part of the validation of your patch.
Follow the project's coding conventions. If the coding convention isn't followed for the project, your patch may appear sloppy as a result and will likely be rejected/ignored by upstream.
Commit messages are as important as the code. It is quite likely that your commit will be viewed months/years/decades after it was written. A good commit message should introduce the problem it's trying to solve, then describe how it solves the problem. For more information please see: A note about git commit messages.
Structure commits. A patchset should be incremental, every patch should be a self-contained logical unit. A patch may depend upon a previous patch, but must not depend on future patches. i.e. After each patch is applied, the project should compile and work. This is important as it allows people to "bisect" and locate where problems occur.
Patches are a guide in themselves. Other people will likely read your patches to understand how the project works. Patches should not contain spurious code changes, and anything introduced should be well documented in the comments and/or commit log.
Communicate Effectively. Please read: How To Ask Questions The Smart Way.
LEG/Engineering/OPTIM/PortingGuidelines (last modified 2013-11-14 16:09:44)