Skip to content

Latest commit

 

History

History
45 lines (25 loc) · 1.82 KB

Hacking.md

File metadata and controls

45 lines (25 loc) · 1.82 KB

A short and sweet hacking guide to Piccolo2D. See also HackersGuide.


### Notes for committers
Try to commit work against some open issue. We're all guilty of not following this sometimes, especially for e.g. checkstyle-related fixes.
When you create a new Issue, leave it as New and without an owner for a little while to allow for comment before assigning it to yourself, moving it to Accepted, assigning a Milestone, etc.
Include the Issue # in your svn commit message, e.g. ``` $ svn commit -m "Issue 123 ; fixed blah blah..." ```
Include the Revision # (either "revision 123 (on Google Code)" or "r123 (on Google Code)") as a comment in the Issue when you commit a fix against an issue. This allows a reviewer to quickly find the diff and start the code review process if necessary. A cut n' paste of the svn commit command gives you the "Committed revision 123 (on Google Code)" note at the bottom.

(or use "Fixes Issue 123 (on Google Code)." in your svn commit message and this will automatically mark the issue as Fixed, check the Google Code docs for details)


Fixed issues should be moved to Verified by either the original submitter or a developer other than the committer of the fix.
There is a checkstyle configuration and a matching Eclipse formatter configuration (though not all of us use Eclipse). Try not to create too many new checkstyle errors, and try to commit formatting-only changes separate from coding changes.
Binary incompatible changes must bump major version numbers (e.g. 1.x --> 2.x).
Revolutionary changes should happen on a branch first.
Project owners/committers don't vote on things very often, it's more proceed until veto.