Preparing Code

If you have a piece of source code (be it a fix, new feature, or optimization of existing code) prepare your changes in a way that makes it easy for the Lindens to incorporate them into the source code.

Good Change Practice

It's easy for the people who review and apply changes to be the bottleneck in the system. If you can make it easier for Lindens to understand, test, and integrate your change, it is much better for everyone concerned.

Before You Start

• Understand and use the Project Snowstorm Processes; making sure that your change is part of the plan is the most important thing you can do to get it accepted.

• You must complete and sign the contribution agreement.

Coding Standard

Please read and follow the coding standard: Second Life coding standard

Comments

Do not add issue numbers and your name to the code itself. While comments explaining code in a general working context are helpful and strongly encouraged, bracketing a change with comments like "// PATCH START" and "// PATCH END" does not add any information, and is likely to get your change returned for revision.

Do not comment out or use the preprocessor to disable code that you are replacing: just delete it. The source control system can find it again if we need it, and leaving dead code around makes things harder to read and much harder to search.

In short, make your change what is expected to appear in the final source.

Give Yourself Credit!

While names and JIRAs shouldn't appear in source, they do belong in doc/contributions.txt. Please don't be shy about adding the issue label and adding your name. If you already have one or more entries in contributions.txt add new ones below the older ones; do not sort your list numerically. Changes to this file are used internally to see what has been done since the last release and to generate statistics.

One Change For One Issue

Each submission should do exactly one thing. If you have three different bugs to fix, please submit three different change sets (unless they are very closely related and being treated as one item in the sprint). If you are unsure whether or not it is ok to combine changes into one submission, ask the Lindens.

Less Is More

Smaller change sets are easier to review and therefore more likely to be integrated quickly. This does not mean that you should omit comments or unit tests, however - adding to those is strongly encouraged.

When The Code Is Ready

See How To Submit A Viewer Change