You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by Apache Wiki <wi...@apache.org> on 2014/12/01 08:24:21 UTC

[Cassandra Wiki] Update of "HowToContribute" by JonathanEllis

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:
https://wiki.apache.org/cassandra/HowToContribute?action=diff&rev1=57&rev2=58

Comment:
r/m obsolete git-svn stuff

  == 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+AND+status+!%3D+resolved|the low-hanging fruit label]] in JIRA.
+  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+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved|the low-hanging fruit label]] in JIRA.
   1. Read the relevant parts of ArchitectureInternals; watching http://www.youtube.com/watch?v=W6e8_IcgJM4 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
@@ -11, +11 @@

    * Verify that you follow Cassandra's CodeStyle.
    * Verify that your change works by adding a unit test.
    * Make sure all tests pass by running "ant test" in the project directory.
-     * You can run specific tests like so: `ant test -Dtest.name=SSTableReaderTest``
+    * You can run specific tests like so: `ant test -Dtest.name=SSTableReaderTest``
    * For testing multi-node behavior, https://github.com/pcmanus/ccm is useful
   1. When you're happy with the result create a patch:
    * git add <any new or modified file>
@@ -32, +32 @@

  
  === Running the dtests ===
  The dtests use [[https://github.com/pcmanus/ccm|ccm]] to test a local cluster.
+ 
   1. Install ccm.  You can do this with pip by running `pip install ccm`.
   1. Install nosetests.  With pip, this is `pip install nose`.
   1. Clone the dtest repo: https://github.com/riptano/cassandra-dtest.git
@@ -45, +46 @@

   1. View `build/cobertura/html/index.html`
  
  === Continuous integration ===
- 
  Buildbot runs the Cassandra tests continuously: http://ci.apache.org/builders/cassandra-trunk.  (Builders for stable branches also exist.)
  
  == IDE ==
@@ -56, +56 @@

    * Main Class for Avro: org.apache.cassandra.avro.CassandraDaemon (Exprimental, introduced in 0.6)
    * VM Parameters: -ea -Xmx1G -Dstorage-config=conf -Dcassandra-foreground
  
- == Ivy ==
- Cassandra uses ivy [http://ant.apache.org/ivy/] to fetch compile-time dependencies.  Ivy needs to be able to access the web servers that host the dependencies (typically maven repositories).  If your internet access is proxied, ivy (ant, really) needs to know about it.  There are two ways to accomplish this:
- 
-  * Include `-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128` in the `ANT_OPTS` environment variable.  See the ant wiki [http://wiki.apache.org/ant/TheElementsOfAntStyle] for more information about `ANT_OPTS`.
-  * Specify these values on the command line: `ant clean build -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128`
- 
- == Got Git? ==
-  * Using git to manage patches during reviews: http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
-  * Uploading and applying patches from JIRA automagically: [[GitAndJIRA]]
- 
- === Branch-specific Git repo ===
- Sometimes it's necessary to create an entirely new repository instance to work on a branch (for example, if you need to work in a separate IDE configuration).  This is particularly common in the long-term support of stable releases.  The following recipe can be used to create a Git repository for tracking/committing to/from a single branch.
- 
- {{{
- mkdir cassandra-0.7
- cd cassandra-0.7
- git init
- git remote add -f -t cassandra-0.7 -m master origin git://github.com/apache/cassandra.git
- 
- git remote set-head origin cassandra-0.7
- git merge origin
- 
- # Git-svn setup
- cd .git; wget http://git.apache.org/authors.txt; cd ..
- git config svn.authorsfile ".git/authors.txt"
- git svn init --prefix=origin/ --branches=branches https://svn.apache.org/repos/asf/cassandra
- }}}
  == Committing ==
  Got commit access?  Outstanding!  Here are the conventions we follow.
  
@@ -94, +67 @@

  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 1.1, 1.2, and trunk, you would first commit to 1.1, and push changes.  Then, switch to your 1.2 branch by doing
+ 
- {{{ 
+ {{{
      git checkout cassandra-1.2
  }}}
-  and run 
+  . and run
+ 
  {{{
      git merge cassandra-1.1
  }}}
- If there are conflicts, resolve them and commit, followed by a push.  Finally, switch to trunk by doing 
+ If there are conflicts, resolve them and commit, followed by a push.  Finally, switch to trunk by doing
+ 
  {{{
      git checkout trunk
  }}}
- and run 
+ and run
+ 
  {{{
      git merge cassandra-1.2
  }}}