Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "HowToContribute" page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/HowToContribute?action=diff&rev1=39&rev2=40 + == Overview == + 1. Pick an issue to work on. If you don't have a specific [[http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html|itch to scratch]], some possibilities are marked with [[https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+12310865+AND+labels+%3D+lhf|the low-hanging fruit label]] in JIRA. 1. Read the relevant parts of ArchitectureInternals; watching http://www.channels.com/episodes/show/11765800/Getting-to-know-the-Cassandra-Codebase will probably also be useful 1. Check if someone else has already begun work on the change you have in mind in the [[https://issues.apache.org/jira/browse/CASSANDRA|issue tracker]] 1. If not, create a ticket describing the change you're proposing in the issue tracker @@ -98, +100 @@ Got commit access? Outstanding! Here are the conventions we follow. Commit messages take the form of + {{{ <explanation> patch by <author>; reviewed by <committer> for CASSANDRA-<ticket> }}} - When committing to multiple branches, start with the most-stable and merge forwards. For instance, if you had a fix to apply to 0.6, 0.7, and trunk, you would first commit to 0.6. Then, from your 0.7 branch checkout, you would run "svn merge https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6";, resolve any conflicts, and commit. Then, from your trunk checkout, you would run "svn merge https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7";, again resolve conflicts, and commit. See http://video.google.com/videoplay?docid=-577744660535947210 for an in-depth explanation of why fixes should be merged forwards from more-stable branches, rather than backported from trunk.
