Version 19 (modified by scythetwirler, 6 years ago) ( diff )

Milestone change.

This document explains the process to submit code patches. This process isn't well suited for art changes, it's best to use the forums to submit new proposed art.

Creating the patch

First you should check out the game code from SVN or an up-to-date Git fork and make some changes.

Make sure you're on the latest version of the code (and merged in your own changes) when making your patch. And try to follow the coding conventions.

If this is your first contribution, please add yourself to the relevant file under ps/trunk/binaries/data/mods/public/gui/credits/texts. You are free to use your real name, your nickname or both.

Go to the "trunk" directory in the source tree, and create a patch, with svn diff (or the equivalent "create patch" feature in TortoiseSVN).

Also try to keep your patches reasonable. Different bugs shouldn't be mixed in the same patch.

When you modify or add methods to simulation components, you should add unit tests that test all added or modified changes.

The RFC queue

Submitting a patch is done by attaching the patch file to a Trac ticket. This can be an existing relevant ticket or a new ticket.

RFC stands for "request for comments". To get the ticket in the RFC queue, you should make sure the ticket looks as follows:

  • The Summary (title of the ticket) should start with [PATCH].
  • The Milestone should be set to 'Work In Progress'.
  • The Keyword list should have the keywords rfc patch.

At this stage, at least one other developer should try to give some comments on the patch (most importantly whether all requirements have been identified, whether the code design is going in the right direction and how the code should be shaped to stay maintainable).

It is advisable to drop by on irc to discuss matters. If the topic involves controversial matter (things that influence balancing or the game design in unforseen ways), it is recommended to create a forum topic for it.

Some patches can take longer to review due to high complexity, lower priority or other circumstances. But it's best to keep in touch with us and ask for reviews.

Note that non-team members can help in the RFC process too by playtesting, checking code quality or even just seeing if it compiles on your system.

When you're already familiar with the codebase and have a patch that won't cause discussions on the code style or implementation of that feature, you can skip the RFC stage, and push the patch to the review queue directly.

The review queue

Once a patch is agreed on during the RFC process, it can be pushed to the review queue. This is done by changing the rfc keyword to review.

At this point, one of the core developers should review the final patch on the following points:

  • Code style (check if the patch follows all Coding Conventions)
  • An in-game test (check if the patch implements the advertised changes)
  • Unit tests (check if the required tests are implemented and the tests still work)
  • Completeness (verifying that there are no files forgotten which require similar changes)

A code quality tool like jshint is recommended to test for non-obvious syntax mistakes.

When the patch passes on all points, it gets committed. When the patch doesn't pass, it will be sent back to the RFC queue.

Legal disclaimer

By sending in a patch, you agree that it is your own work (or else make it clear where it came from) and agree to licensing any code as GPL 2+ (or in some cases MIT, especially for code in lib/ - check the existing copyright headers on the source files you edit) and data files as CC-BY-SA 3.0.

Note: See TracWiki for help on using the wiki.