[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=diffrev1=57rev2=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=truejqlQuery=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=truejqlQuery=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
[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=diffrev1=49rev2=50 Comment: replace 2011 internals talk w/ 2013 == 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=truejqlQuery=project+%3D+12310865+AND+labels+%3D+lhf+AND+status+!%3D+resolved|the low-hanging fruit label]] in JIRA. - 1. Read the relevant parts of ArchitectureInternals; watching http://blip.tv/datastax/getting-to-know-the-cassandra-codebase-4034648 will probably also be useful + 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 1. Check out the latest version of the source code
[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: http://wiki.apache.org/cassandra/HowToContribute?action=diffrev1=43rev2=44 Comment: add buildbot link 1. `/path/to/cobertura/cobertura-report.sh --destination build/cobertura/html source code src/java` 1. View `build/cobertura/html/index.html` - This is also available on Hudson (which updates about once every 24h) here: http://hudson.zones.apache.org/hudson/job/Cassandra/cobertura/ + === Continuous integration === - (If you are getting File.deleteOnExit() exceptions, older versions of cobertura are broken with JVM 1.6.0_14+.) + Buildbot runs the Cassandra tests continuously: http://ci.apache.org/builders/cassandra-trunk. (Builders for stable branches also exist.) == IDE == * [[RunningCassandraInIDEA]]
[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:
http://wiki.apache.org/cassandra/HowToContribute?action=diffrev1=39rev2=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=truejqlQuery=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.
[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: http://wiki.apache.org/cassandra/HowToContribute?action=diffrev1=38rev2=39 Comment: link cassandra codebase talk and ccm - 1. Read the relevant parts of ArchitectureInternals + 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 1. Check out the latest version of the source code @@ -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. + * For testing multi-node behavior, https://github.com/pcmanus/ccm is useful 1. When you're happy with the result create a patch: * svn add any new file * svn diff branchname-issue.txt (e.g. trunk-123.txt, cassandra-0.6-123.txt)
[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.
The comment on this change is: add section on svn merging.
http://wiki.apache.org/cassandra/HowToContribute?action=diffrev1=33rev2=34
--
1. If not, create a ticket describing the change you're proposing in the
issue tracker
1. Check out the latest version of the source code
* svn checkout http://svn.apache.org/repos/asf/cassandra/trunk
cassandra-trunk
- or
+. or
* git clone git://git.apache.org/cassandra.git
1. Modify the source to include the improvement/bugfix
* Verify that you follow Cassandra's CodeStyle.
@@ -37, +37 @@
''Note: If you're setup with both the Thrift and Avro dependencies, you can
run all of the tests by simply typing `nosetests` from the top-level directory''
=== Running the code coverage task ===
-
1. Unzip this one:
http://sourceforge.net/projects/cobertura/files/cobertura/1.9.4.1/cobertura-1.9.4.1-bin.zip/download
1. `ant codecoverage -Dcobertura.dir=/path/to/cobertura`
1. `/path/to/cobertura/cobertura-report.sh --destination
build/cobertura/html source code src/java`
@@ -49, +48 @@
== IDE ==
* [[RunningCassandraInIDEA]]
- * [[RunningCassandraInEclipse]]
+ * RunningCassandraInEclipse
* IntelliJ Project Settings:
* Main Class for Thrift: org.apache.cassandra.thrift.CassandraDaemon (Used
to be org.apache.cassandra.service.CassandraDaemon )
* Main Class for Avro: org.apache.cassandra.avro.CassandraDaemon
(Exprimental, introduced in 0.6)
@@ -99, +98 @@
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.
+ * 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.
+
+ This workflow also makes it so svn knows what commits have been made to
earlier branches but not to trunk: if you forget to merge a fix immediately,
the next time someone goes to merge from the branch, svn will incorporate the
forgotten ones too.
+
