Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 8 additions & 18 deletions akka-docs/rst/dev/developer-guidelines.rst
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ Developer Guidelines

.. note::

First read `The Akka Contributor Guidelines <https://github.com/akka/akka/blob/master/CONTRIBUTING.md>`_ .
First read `The Akka Contributor Guidelines`_.

Code Style
----------
Expand All @@ -28,30 +28,18 @@ Akka is using ``Scalariform`` to format the source code as part of the build. So
Process
-------

The full process is described in `The Akka Contributor Guidelines`_. In summary:

* Make sure you have signed the Akka CLA, if not, `sign it online <http://www.typesafe.com/contribute/cla>`_.
* Pick a ticket, if there is no ticket for your work then create one first.
* Start working in a feature branch. Name it something like ``wip-<ticket number>-<descriptive name>-<your username>``.
* When you are done, create a GitHub Pull-Request towards the targeted branch and email the Akka Mailing List that you want it reviewed
* Fork `akka/akka <https://github.com/akka/akka>`_. Start working in a feature branch.
* When you are done, create a GitHub Pull-Request towards the targeted branch.
* When there's consensus on the review, someone from the Akka Core Team will merge it.

Commit messages
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of lines above it mentions that after submitting a PR one should email Akka Mailing List, which should probably go.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

---------------

Please follow these guidelines when creating public commits and writing commit messages.

1. If your work spans multiple local commits (for example; if you do safe point commits while working in a topic branch or work in a branch for long time doing merges/rebases etc.) then please do **not** commit it all but rewrite the history by squashing the commits into a single big commit which you write a good commit message for (like discussed below). Here is a great article for how to do that: `http://sandofsky.com/blog/git-workflow.html <http://sandofsky.com/blog/git-workflow.html>`_. Every commit should be able to be used in isolation, cherry picked etc.

2. First line should be a descriptive sentence what the commit is doing. It should be possible to fully understand what the commit does by just reading this single line. It is **not** ok to only list the ticket number, type "minor fix" or similar. Include reference to ticket number, prefixed with #, at the end of the first line. If the commit is a **small** fix, then you are done. If not, go to 3.

3. Following the single line description should be a blank line followed by an enumerated list with the details of the commit.

Example::

Completed replication over BookKeeper based transaction log. Fixes #XXX

* Details 1
* Details 2
* Details 3
Please follow the conventions described in `The Akka Contributor Guidelines`_ when creating public commits and writing commit messages.

Testing
-------
Expand All @@ -77,3 +65,5 @@ NetworkFailureTest
^^^^^^^^^^^^^^^^^^

You can use the 'NetworkFailureTest' trait to test network failure.

.. _The Akka Contributor Guidelines: https://github.com/akka/akka/blob/master/CONTRIBUTING.md