Changeset - 49be3b49c8e2
[Not reviewed]
default
0 1 0
Karl Goetz - 8 years ago 2017-06-28 21:52:35
karl@kgoetz.id.au
docs/contributing: make contribution information more accessible

Try to make the contribution information more accessible to new users, by
giving a bit more detail about the different steps in making contributions.

Some rework of the original patch done by Thomas De Schampheleire:
- don't give the impression that Bitbucket is mandatory
- don't recommend creating feature branches for regular development
- reword/cross-reference section on contribution flow
1 file changed with 42 insertions and 3 deletions:
0 comments (0 inline, 0 general)
docs/contributing.rst
Show inline comments
 
@@ -7,63 +7,96 @@ Contributing to Kallithea
 
Kallithea is developed and maintained by its users. Please join us and scratch
 
your own itch.
 

	
 

	
 
Infrastructure
 
--------------
 

	
 
The main repository is hosted on Our Own Kallithea (aka OOK) at
 
https://kallithea-scm.org/repos/kallithea/, our self-hosted instance
 
of Kallithea.
 

	
 
For now, we use Bitbucket_ for `pull requests`_ and `issue tracking`_. The
 
issue tracker is for tracking bugs, not for support, discussion, or ideas --
 
please use the `mailing list`_ or :ref:`IRC <readme>` to reach the community.
 

	
 
We use Weblate_ to translate the user interface messages into languages other
 
than English. Join our project on `Hosted Weblate`_ to help us.
 
To register, you can use your Bitbucket or GitHub account. See :ref:`translations`
 
for more details.
 

	
 

	
 
Getting started
 
---------------
 

	
 
To get started with development::
 
To get started with Kallithea development::
 

	
 
        hg clone https://kallithea-scm.org/repos/kallithea
 
        cd kallithea
 
        virtualenv ../kallithea-venv
 
        source ../kallithea-venv/bin/activate
 
        pip install --upgrade pip setuptools
 
        pip install -e .
 
        gearbox make-config my.ini
 
        gearbox setup-db -c my.ini --user=user --email=user@example.com --password=password --repos=/tmp
 
        gearbox serve -c my.ini --reload &
 
        firefox http://127.0.0.1:5000/
 

	
 
You can also start out by forking https://bitbucket.org/conservancy/kallithea
 
on Bitbucket_ and create a local clone of your own fork.
 
If you plan to use Bitbucket_ for sending contributions, you can also fork
 
Kallithea on Bitbucket_ first (https://bitbucket.org/conservancy/kallithea) and
 
then replace the clone step above by a clone of your fork. In this case, please
 
see :ref:`contributing-guidelies` below for configuring your fork correctly.
 

	
 

	
 
Contribution flow
 
-----------------
 

	
 
Starting from an existing Kallithea clone, make sure it is up to date with the
 
latest upstream changes::
 

	
 
        hg pull
 
        hg update
 

	
 
Review the :ref:`contributing-guidelines` and :ref:`coding-guidelines`.
 

	
 
If you are new to Mercurial, refer to Mercurial `Quick Start`_ and `Beginners
 
Guide`_ on the Mercurial wiki.
 

	
 
Now, make some changes and test them (see :ref:`contributing-tests`). Don't
 
forget to add new tests to cover new functionality or bug fixes.
 

	
 
For documentation changes, run ``make html`` from the ``docs`` directory to
 
generate the HTML result, then review them in your browser.
 

	
 
Before submitting any changes, run the cleanup script::
 

	
 
        ./scripts/run-all-cleanup
 

	
 
When you are completely ready, you can send your changes to the community for
 
review and inclusion. Most commonly used methods are sending patches to the
 
mailing list (via ``hg email``) or by creating a pull request on Bitbucket_.
 

	
 
.. _contributing-tests:
 

	
 

	
 
Running tests
 
-------------
 

	
 
After finishing your changes make sure all tests pass cleanly. Install the test
 
dependencies, then run the testsuite by invoking ``py.test`` from the
 
project root::
 

	
 
    pip install -r dev_requirements.txt
 
    py.test
 

	
 
Note that testing on Python 2.6 also requires ``unittest2``.
 

	
 
Note that on unix systems, the temporary directory (``/tmp`` or where
 
``$TMPDIR`` points) must allow executable files; Git hooks must be executable,
 
and the test suite creates repositories in the temporary directory. Linux
 
systems with /tmp mounted noexec will thus fail.
 

	
 
You can also use ``tox`` to run the tests with all supported Python versions
 
(currently Python 2.6--2.7).
 

	
 
When running tests, Kallithea uses `kallithea/tests/test.ini` and populates the
 
SQLite database specified there.
 
@@ -93,87 +126,91 @@ are::
 
                          all if none failed)
 
    --ff                  run all tests but run the last failures first. This
 
                          may re-order tests and thus lead to repeated fixture
 
                          setup/teardown
 
    --pdb                 start the interactive Python debugger on errors.
 
    -s, --capture=no      don't capture stdout (any stdout output will be
 
                          printed immediately)
 

	
 
Performance tests
 
^^^^^^^^^^^^^^^^^
 

	
 
A number of performance tests are present in the test suite, but they are
 
not run in a standard test run. These tests are useful to
 
evaluate the impact of certain code changes with respect to performance.
 

	
 
To run these tests::
 

	
 
    env TEST_PERFORMANCE=1 py.test kallithea/tests/performance
 

	
 
To analyze performance, you could install pytest-profiling_, which enables the
 
--profile and --profile-svg options to py.test.
 

	
 
.. _pytest-profiling: https://github.com/manahl/pytest-plugins/tree/master/pytest-profiling
 

	
 
.. _contributing-guidelines:
 

	
 

	
 
Contribution guidelines
 
-----------------------
 

	
 
Kallithea is GPLv3 and we assume all contributions are made by the
 
committer/contributor and under GPLv3 unless explicitly stated. We do care a
 
lot about preservation of copyright and license information for existing code
 
that is brought into the project.
 

	
 
Contributions will be accepted in most formats -- such as pull requests on
 
Bitbucket, something hosted on your own Kallithea instance, or patches sent by
 
email to the `kallithea-general`_ mailing list.
 

	
 
When contributing via Bitbucket, please make your fork of
 
https://bitbucket.org/conservancy/kallithea/ `non-publishing`_ -- it is one of
 
the settings on "Repository details" page. This ensures your commits are in
 
"draft" phase and makes it easier for you to address feedback and for project
 
maintainers to integrate your changes.
 

	
 
.. _non-publishing: https://www.mercurial-scm.org/wiki/Phases#Publishing_Repository
 

	
 
Make sure to test your changes both manually and with the automatic tests
 
before posting.
 

	
 
We care about quality and review and keeping a clean repository history. We
 
might give feedback that requests polishing contributions until they are
 
"perfect". We might also rebase and collapse and make minor adjustments to your
 
changes when we apply them.
 

	
 
We try to make sure we have consensus on the direction the project is taking.
 
Everything non-sensitive should be discussed in public -- preferably on the
 
mailing list.  We aim at having all non-trivial changes reviewed by at least
 
one other core developer before pushing. Obvious non-controversial changes will
 
be handled more casually.
 

	
 
For now we just have one official branch ("default") and will keep it so stable
 
that it can be (and is) used in production. Experimental changes should live
 
elsewhere (for example in a pull request) until they are ready.
 

	
 
.. _coding-guidelines:
 

	
 

	
 
Coding guidelines
 
-----------------
 

	
 
We don't have a formal coding/formatting standard. We are currently using a mix
 
of Mercurial's (https://www.mercurial-scm.org/wiki/CodingStyle), pep8, and
 
consistency with existing code. Run ``scripts/run-all-cleanup`` before
 
committing to ensure some basic code formatting consistency.
 

	
 
We support both Python 2.6.x and 2.7.x and nothing else. For now we don't care
 
about Python 3 compatibility.
 

	
 
We try to support the most common modern web browsers. IE9 is still supported
 
to the extent it is feasible, IE8 is not.
 

	
 
We primarily support Linux and OS X on the server side but Windows should also work.
 

	
 
HTML templates should use 2 spaces for indentation ... but be pragmatic. We
 
should use templates cleverly and avoid duplication. We should use reasonable
 
semantic markup with element classes and IDs that can be used for styling and testing.
 
We should only use inline styles in places where it really is semantic (such as
 
``display: none``).
 

	
 
JavaScript must use ``;`` between/after statements. Indentation 4 spaces. Inline
 
@@ -251,24 +288,26 @@ To enable DebugBar, install ``tgext.debu
 
``pip``) and restart Kallithea (in debug mode).
 

	
 

	
 
"Roadmap"
 
---------
 

	
 
We do not have a road map but are waiting for your contributions. Refer to the
 
wiki_ for some ideas of places we might want to go -- contributions in these
 
areas are very welcome.
 

	
 

	
 
Thank you for your contribution!
 
--------------------------------
 

	
 

	
 
.. _Weblate: http://weblate.org/
 
.. _issue tracking: https://bitbucket.org/conservancy/kallithea/issues?status=new&status=open
 
.. _pull requests: https://bitbucket.org/conservancy/kallithea/pull-requests
 
.. _bitbucket: http://bitbucket.org/
 
.. _mailing list: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
 
.. _kallithea-general: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
 
.. _Hosted Weblate: https://hosted.weblate.org/projects/kallithea/kallithea/
 
.. _wiki: https://bitbucket.org/conservancy/kallithea/wiki/Home
 
.. _DebugBar: https://github.com/TurboGears/tgext.debugbar
 
.. _Quick Start: https://www.mercurial-scm.org/wiki/QuickStart
 
.. _Beginners Guide: https://www.mercurial-scm.org/wiki/BeginnersGuides
0 comments (0 inline, 0 general)