kallithea Changeset - a755bacaa725

Changeset - a755bacaa725

Parent rev.

Child rev.

[Not reviewed]

default

0 1 0

Thomas De Schampheleire - 8 years ago 2017-06-28 21:26:21
thomas.de.schampheleire@gmail.com

docs/contributing: clarify that Kallithea now also has a stable branch

1 file changed with 5 insertions and 3 deletions:

docs/contributing.rst

0 comments (0 inline, 0 general)

docs/contributing.rst

➞

Show inline comments

@@ @@ -162,51 +162,53 @@ Bitbucket, something hosted on your own @@
 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.
 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:
 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

0 comments (0 inline, 0 general)