Changeset - 26fcb8c16c2c
[Not reviewed]
default
0 1 0
Thomas De Schampheleire - 5 years ago 2020-10-09 19:31:44
thomas.de_schampheleire@nokia.com
docs/contributing: wrap long line

Forgotten review comment.
1 file changed with 3 insertions and 2 deletions:
0 comments (0 inline, 0 general)
docs/contributing.rst
Show inline comments
 
@@ -138,50 +138,51 @@ 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 commits hosted on your own Kallithea instance, or patches sent by
 
email to the `kallithea-general`_ mailing list.
 
Contributions will be accepted in most formats -- such as commits hosted on your
 
own Kallithea instance, or patches sent by email to the `kallithea-general`_
 
mailing list.
 

	
 
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.
 

	
 
There is a main development branch ("default") which is generally stable so that
 
it can be (and is) used in production. There is also a "stable" branch that is
 
almost exclusively reserved for bug fixes or trivial changes. Experimental
 
changes should live elsewhere (for example in a pull request) until they are
 
ready.
 

	
 
.. _coding-guidelines:
 

	
 

	
0 comments (0 inline, 0 general)