raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11

=doc switch to GitHub Issues

Browse source 
also remove the `experimental` marker from multi-node-testing’s docs
This commit is contained in:
Roland Kuhn 2014-04-13 18:34:35 +02:00
parent 3179a02044
commit 6947f15084
3 changed files with 34 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

27
CONTRIBUTING.md
View file

@ -16,19 +16,31 @@ These guidelines mainly applies to Typesafe’s “mature” projects - not nece
This is the process for committing code into master. There are of course exceptions to these rules, for example minor changes to comments and documentation, fixing a broken build etc. This is the process for committing code into master. There are of course exceptions to these rules, for example minor changes to comments and documentation, fixing a broken build etc.
1. Make sure you have signed the [Typesafe CLA](http://www.typesafe.com/contribute/cla), if not, sign it online. 1. Make sure you have signed the Typesafe CLA, if not, [sign it online](http://www.typesafe.com/contribute/cla).
2. Before starting to work on a feature or a fix, you have to make sure that: 2. Before starting to work on a feature or a fix, make sure that:
1. There is a ticket for your work in the project's issue tracker. If not, create it first. 1. There is a ticket for your work in the project's issue tracker. If not, create it first.
2. The ticket has been scheduled for the current milestone. 2. The ticket has been scheduled for the current milestone.
3. The ticket is estimated by the team. 3. The ticket is estimated by the team.
4. The ticket have been discussed and prioritized by the team. 4. The ticket have been discussed and prioritized by the team.
3. You should always perform your work in a Git feature branch. The branch should be given a descriptive name that explains its intent. Some teams also like adding the ticket number and/or the [GitHub](http://github.com) user ID to the branch name, these details is up to each of the individual teams. 3. You should always perform your work in a Git feature branch. The branch should be given a descriptive name that explains its intent. Some teams also like adding the ticket number and/or the [GitHub](http://github.com) user ID to the branch name, these details is up to each of the individual teams.
Akka prefers the committer name as part of the branch name, the ticket number is optional.
4. When the feature or fix is completed you should open a [Pull Request](https://help.github.com/articles/using-pull-requests) on GitHub. 4. When the feature or fix is completed you should open a [Pull Request](https://help.github.com/articles/using-pull-requests) on GitHub.
5. The Pull Request should be reviewed by other maintainers (as many as feasible/practical). Note that the maintainers can consist of outside contributors, both within and outside Typesafe. Outside contributors (for example from EPFL or independent committers) are encouraged to participate in the review process, it is not a closed process. 5. The Pull Request should be reviewed by other maintainers (as many as feasible/practical). Note that the maintainers can consist of outside contributors, both within and outside Typesafe. Outside contributors (for example from EPFL or independent committers) are encouraged to participate in the review process, it is not a closed process.
6. After the review you should fix the issues as needed (pushing a new commit for new review etc.), iterating until the reviewers give their thumbs up. 6. After the review you should fix the issues as needed (pushing a new commit for new review etc.), iterating until the reviewers give their thumbs up.
7. Once the code has passed review the Pull Request can be merged into the master branch.
When the branch conflicts with its merge target (either by way of git merge conflict or failing CI tests), do **not** merge the target branch into your feature branch. Instead rebase your branch onto the target branch. Merges complicate the git history, especially for the squashing which is necessary later (see below).
7. Once the code has passed review the Pull Request can be merged into the master branch. For this purpose the commits which were added on the feature branch should be squashed into a single commit. This can be done using the command `git rebase -i master` (or the appropriate target branch), `pick`ing the first commit and `squash`ing all following ones.
Also make sure that the commit message conforms to the syntax specified below.
8. If the code change needs to be applied to other branches as well, create pull requests against those branches which contain the change after rebasing it onto the respective branch and await successful verification by the continuous integration infrastructure; then merge those pull requests. 8. If the code change needs to be applied to other branches as well, create pull requests against those branches which contain the change after rebasing it onto the respective branch and await successful verification by the continuous integration infrastructure; then merge those pull requests.
9. Once everything is said and done, associate the ticket with the “earliest” release branch (i.e. if back-ported so that it will be in release x.y.z, find the relevant milestone for that release) and close it.
Please mark these pull requests with `(for validation)` in the title to make the purpose clear in the pull request list.
9. Once everything is said and done, associate the ticket with the “earliest” release milestone (i.e. if back-ported so that it will be in release x.y.z, find the relevant milestone for that release) and close it.
## Pull Request Requirements ## Pull Request Requirements
@ -59,18 +71,18 @@ Whether or not a pull request (or parts of it) shall be back- or forward-ported
## Continuous Integration ## Continuous Integration
Each project should be configured to use a continuous integration (CI) tool (i.e. a build server ala Jenkins). Typesafe has a Jenkins server farm that can be used. The CI tool should, on each push to master, build the **full** distribution and run **all** tests, and if something fails it should email out a notification with the failure report to the committer and the core team. The CI tool should also be used in conjunction with Typesafe’s Pull Request Validator (discussed below). Each project should be configured to use a continuous integration (CI) tool (i.e. a build server à la Jenkins). Typesafe has a Jenkins server farm that can be used. The CI tool should, on each push to master, build the **full** distribution and run **all** tests, and if something fails it should email out a notification with the failure report to the committer and the core team. The CI tool should also be used in conjunction with Typesafe’s Pull Request Validator (discussed below).
## Documentation ## Documentation
All documentation should be generated using the sbt-site-plugin, *or* publish artifacts to a repository that can be consumed by the typesafe stack. All documentation should be generated using the sbt-site-plugin, *or* publish artifacts to a repository that can be consumed by the Typesafe stack.
All documentation must abide by the following maxims: All documentation must abide by the following maxims:
- Example code should be run as part of an automated test suite. - Example code should be run as part of an automated test suite.
- Version should be **programmatically** specifiable to the build. - Version should be **programmatically** specifiable to the build.
- Generation should be **completely automated** and available for scripting. - Generation should be **completely automated** and available for scripting.
- Artifacts that must be included in the Typesafe Stack should be published to a maven “documentation” repository as documentation artifacts. - Artifacts that must be included in the Typesafe stack should be published to a maven “documentation” repository as documentation artifacts.
All documentation is preferred to be in Typesafe's standard documentation format [reStructuredText](http://doc.akka.io/docs/akka/snapshot/dev/documentation.html) compiled using Typesafe's customized [Sphinx](http://sphinx.pocoo.org/) based documentation generation system, which among other things allows all code in the documentation to be externalized into compiled files and imported into the documentation. All documentation is preferred to be in Typesafe's standard documentation format [reStructuredText](http://doc.akka.io/docs/akka/snapshot/dev/documentation.html) compiled using Typesafe's customized [Sphinx](http://sphinx.pocoo.org/) based documentation generation system, which among other things allows all code in the documentation to be externalized into compiled files and imported into the documentation.
@ -89,6 +101,7 @@ This must be ensured by manually verifying the license for all the dependencies
3. Whenever a new release is cut (public or private for a customer). 3. Whenever a new release is cut (public or private for a customer).
Which licenses are compatible with Apache 2 are defined in [this doc](http://www.apache.org/legal/3party.html#category-a), where you can see that the licenses that are listed under ``Category A`` automatically compatible with Apache 2, while the ones listed under ``Category B`` needs additional action: Which licenses are compatible with Apache 2 are defined in [this doc](http://www.apache.org/legal/3party.html#category-a), where you can see that the licenses that are listed under ``Category A`` automatically compatible with Apache 2, while the ones listed under ``Category B`` needs additional action:
> Each license in this category requires some degree of [reciprocity](http://www.apache.org/legal/3party.html#define-reciprocal); therefore, additional action must be taken in order to minimize the chance that a user of an Apache product will create a derivative work of a reciprocally-licensed portion of an Apache product without being aware of the applicable requirements. > Each license in this category requires some degree of [reciprocity](http://www.apache.org/legal/3party.html#define-reciprocal); therefore, additional action must be taken in order to minimize the chance that a user of an Apache product will create a derivative work of a reciprocally-licensed portion of an Apache product without being aware of the applicable requirements.
Each project must also create and maintain a list of all dependencies and their licenses, including all their transitive dependencies. This can be done in either in the documentation or in the build file next to each dependency. Each project must also create and maintain a list of all dependencies and their licenses, including all their transitive dependencies. This can be done in either in the documentation or in the build file next to each dependency.

4
akka-docs/rst/dev/multi-node-testing.rst
View file

@ -4,10 +4,6 @@
Multi Node Testing Multi Node Testing
################### ###################
.. note:: This module is :ref:`experimental <experimental>`. This document describes how to use the features
implemented so far. More features are coming in Akka Coltrane. Track progress of the Coltrane milestone in
`Assembla <http://www.assembla.com/spaces/akka/milestones/418132-coltrane>`_.
Multi Node Testing Concepts Multi Node Testing Concepts
=========================== ===========================

23
akka-docs/rst/project/issue-tracking.rst
View file

@ -3,7 +3,7 @@
Issue Tracking Issue Tracking
============== ==============
Akka is using ``Assembla`` as its issue tracking system. Akka is using GitHub Issues as its issue tracking system.
Browsing Browsing
-------- --------
@ -11,25 +11,28 @@ Browsing
Tickets Tickets
^^^^^^^ ^^^^^^^
`You can find the Akka tickets here <http://www.assembla.com/spaces/akka/tickets>`_ Before filing a ticket, please check the existing `Akka tickets
<https://github.com/akka/akka/issues>`_ for earlier reports of the same
problem. You are very welcome to comment on existing tickets, especially if you
have reproducible test cases that you can share.
Roadmaps Roadmaps
^^^^^^^^ ^^^^^^^^
`The roadmap for each Akka milestone is here <https://docs.google.com/document/d/18W9-fKs55wiFNjXL9q50PYOnR7-nnsImzJqHOPPbM4E/pub>`_ Please refer to the `Akka roadmap
<https://docs.google.com/document/d/18W9-fKs55wiFNjXL9q50PYOnR7-nnsImzJqHOPPbM4E/pub>`_
in order to find out the general theme of work to be done for upcoming versions
of Akka.
Creating tickets Creating tickets
---------------- ----------------
In order to create tickets you need to do the following: *Please include the versions of Scala and Akka and relevant configuration files.*
`Register here <https://www.assembla.com/user/signup>`_ then log in You can create a `new ticket <https://github.com/akka/akka/issues/new>`_ if you
have registered a GitHub user account.
Then you also need to become a "Watcher" of the Akka space. Thanks a lot for reporting bugs and suggesting features!
`Link to create a new ticket <https://www.assembla.com/spaces/akka/tickets/new>`__
Thanks a lot for reporting bugs and suggesting features. *Please include the versions of Scala and Akka and relevant configuration files.*