cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "HowToContribute" by JonathanEllis
Date Mon, 01 Dec 2014 07:24:21 GMT
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
  }}}

Mime
View raw message