Show More
@@ -1,160 +1,167 b'' | |||||
1 | .. _contributing: |
|
1 | .. _contributing: | |
2 |
|
2 | |||
3 | ========================= |
|
3 | ========================= | |
4 | Contributing to Kallithea |
|
4 | Contributing to Kallithea | |
5 | ========================= |
|
5 | ========================= | |
6 |
|
6 | |||
7 | Kallithea is developed and maintained by its users. Please join us and scratch |
|
7 | Kallithea is developed and maintained by its users. Please join us and scratch | |
8 | your own itch. |
|
8 | your own itch. | |
9 |
|
9 | |||
10 |
|
10 | |||
11 | Infrastructure |
|
11 | Infrastructure | |
12 | -------------- |
|
12 | -------------- | |
13 |
|
13 | |||
14 | The main repository is hosted at Our Own Kallithea (aka OOK) on |
|
14 | The main repository is hosted at Our Own Kallithea (aka OOK) on | |
15 | https://kallithea-scm.org/repos/kallithea/ (which is our self-hosted instance |
|
15 | https://kallithea-scm.org/repos/kallithea/ (which is our self-hosted instance | |
16 | of Kallithea). |
|
16 | of Kallithea). | |
17 |
|
17 | |||
18 | For now, we use Bitbucket_ for `Pull Requests`_ and `Issue Tracker`_ services. The |
|
18 | For now, we use Bitbucket_ for `Pull Requests`_ and `Issue Tracker`_ services. The | |
19 | issue tracker is for tracking bugs, not for "support", discussion or ideas - |
|
19 | issue tracker is for tracking bugs, not for "support", discussion or ideas - | |
20 | please use the `mailing list`_ to reach the community. |
|
20 | please use the `mailing list`_ to reach the community. | |
21 |
|
21 | |||
22 | We use Weblate_ to translate the user interface messages into languages other |
|
22 | We use Weblate_ to translate the user interface messages into languages other | |
23 | than English. Join our project on `Hosted Weblate`_ to help us. |
|
23 | than English. Join our project on `Hosted Weblate`_ to help us. | |
24 | To register, you can use your Bitbucket or GitHub account. |
|
24 | To register, you can use your Bitbucket or GitHub account. | |
25 |
|
25 | |||
26 |
|
26 | |||
27 | Getting started |
|
27 | Getting started | |
28 | --------------- |
|
28 | --------------- | |
29 |
|
29 | |||
30 | To get started with development:: |
|
30 | To get started with development:: | |
31 |
|
31 | |||
32 | hg clone https://kallithea-scm.org/repos/kallithea |
|
32 | hg clone https://kallithea-scm.org/repos/kallithea | |
33 | cd kallithea |
|
33 | cd kallithea | |
34 | virtualenv ../kallithea-venv |
|
34 | virtualenv ../kallithea-venv | |
35 | source ../kallithea-venv/bin/activate |
|
35 | source ../kallithea-venv/bin/activate | |
36 | python setup.py develop |
|
36 | python setup.py develop | |
37 | paster make-config Kallithea my.ini |
|
37 | paster make-config Kallithea my.ini | |
38 | paster setup-db my.ini --user=user --email=user@example.com --password=password --repos=/tmp |
|
38 | paster setup-db my.ini --user=user --email=user@example.com --password=password --repos=/tmp | |
39 | paster serve my.ini --reload & |
|
39 | paster serve my.ini --reload & | |
40 | firefox http://127.0.0.1:5000/ |
|
40 | firefox http://127.0.0.1:5000/ | |
41 |
|
41 | |||
42 | You can also start out by forking https://bitbucket.org/conservancy/kallithea |
|
42 | You can also start out by forking https://bitbucket.org/conservancy/kallithea | |
43 | on Bitbucket_ and create a local clone of your own fork. |
|
43 | on Bitbucket_ and create a local clone of your own fork. | |
44 |
|
44 | |||
45 |
|
45 | |||
46 | Running tests |
|
46 | Running tests | |
47 | ------------- |
|
47 | ------------- | |
48 |
|
48 | |||
49 | After finishing your changes make sure all tests pass cleanly. You can run |
|
49 | After finishing your changes make sure all tests pass cleanly. You can run | |
50 | the testsuite running ``nosetest`` from the project root, or if you use tox |
|
50 | the testsuite running ``nosetests`` from the project root, or if you use tox | |
51 |
run tox for python2.6-2.7 with multiple database test. |
|
51 | run ``tox`` for python2.6-2.7 with multiple database test. | |
52 | test.ini file is used and by default it uses SQLite for tests, edit this file |
|
|||
53 | to change your testing enviroment. |
|
|||
54 |
|
52 | |||
55 | There's a special set of tests for push/pull operations, you can run them using:: |
|
53 | When using `nosetests`, the `test.ini` file is used with an SQLite database. Edit | |
|
54 | this file to change your testing enviroment. | |||
|
55 | ||||
|
56 | It is possible to avoid recreating the full test database on each invocation of | |||
|
57 | the tests, thus eliminating the initial delay. To achieve this, run the tests as:: | |||
56 |
|
58 | |||
57 | paster serve test.ini --pid-file=test.pid --daemon |
|
59 | paster serve test.ini --pid-file=test.pid --daemon | |
58 |
KALLITHEA_WHOOSH_TEST_DISABLE=1 KALLITHEA_NO_TMP_PATH=1 nosetests |
|
60 | KALLITHEA_WHOOSH_TEST_DISABLE=1 KALLITHEA_NO_TMP_PATH=1 nosetests | |
59 | kill -9 $(cat test.pid) |
|
61 | kill -9 $(cat test.pid) | |
60 |
|
62 | |||
|
63 | You can run individual tests by specifying their path as argument to nosetests. | |||
|
64 | nosetests also has many more options, see `nosetests -h`. | |||
|
65 | ||||
|
66 | There's a special set of tests for push/pull operations in | |||
|
67 | `kallithea/tests/other/test_vcs_operations.py`. | |||
61 |
|
68 | |||
62 | Coding/contribution guidelines |
|
69 | Coding/contribution guidelines | |
63 | ------------------------------ |
|
70 | ------------------------------ | |
64 |
|
71 | |||
65 | Kallithea is GPLv3 and we assume all contributions are made by the |
|
72 | Kallithea is GPLv3 and we assume all contributions are made by the | |
66 | committer/contributor and under GPLv3 unless explicitly stated. We do care a |
|
73 | committer/contributor and under GPLv3 unless explicitly stated. We do care a | |
67 | lot about preservation of copyright and license information for existing code |
|
74 | lot about preservation of copyright and license information for existing code | |
68 | that is brought into the project. |
|
75 | that is brought into the project. | |
69 |
|
76 | |||
70 | We don't have a formal coding/formatting standard. We are currently using a mix |
|
77 | We don't have a formal coding/formatting standard. We are currently using a mix | |
71 | of Mercurial (http://mercurial.selenic.com/wiki/CodingStyle), pep8, and |
|
78 | of Mercurial (http://mercurial.selenic.com/wiki/CodingStyle), pep8, and | |
72 | consistency with existing code. Run whitespacecleanup.sh to avoid stupid |
|
79 | consistency with existing code. Run whitespacecleanup.sh to avoid stupid | |
73 | whitespace noise in your patches. |
|
80 | whitespace noise in your patches. | |
74 |
|
81 | |||
75 | We support both Python 2.6.x and 2.7.x and nothing else. For now we don't care |
|
82 | We support both Python 2.6.x and 2.7.x and nothing else. For now we don't care | |
76 | about Python 3 compatibility. |
|
83 | about Python 3 compatibility. | |
77 |
|
84 | |||
78 | We try to support the most common modern web browsers. IE8 is still supported |
|
85 | We try to support the most common modern web browsers. IE8 is still supported | |
79 | to the extent it is feasible but we may stop supporting it very soon. |
|
86 | to the extent it is feasible but we may stop supporting it very soon. | |
80 |
|
87 | |||
81 | We primarily support Linux and OS X on the server side but Windows should also work. |
|
88 | We primarily support Linux and OS X on the server side but Windows should also work. | |
82 |
|
89 | |||
83 | Html templates should use 2 spaces for indentation ... but be pragmatic. We |
|
90 | Html templates should use 2 spaces for indentation ... but be pragmatic. We | |
84 | should use templates cleverly and avoid duplication. We should use reasonable |
|
91 | should use templates cleverly and avoid duplication. We should use reasonable | |
85 | semantic markup with classes and ids that can be used for styling and testing. |
|
92 | semantic markup with classes and ids that can be used for styling and testing. | |
86 | We should only use inline styles in places where it really is semantic (such as |
|
93 | We should only use inline styles in places where it really is semantic (such as | |
87 | display:none). |
|
94 | display:none). | |
88 |
|
95 | |||
89 | JavaScript must use ';' between/after statements. Indentation 4 spaces. Inline |
|
96 | JavaScript must use ';' between/after statements. Indentation 4 spaces. Inline | |
90 | multiline functions should be indented two levels - one for the () and one for |
|
97 | multiline functions should be indented two levels - one for the () and one for | |
91 | {}. jQuery value arrays should have a leading $. |
|
98 | {}. jQuery value arrays should have a leading $. | |
92 |
|
99 | |||
93 | Commit messages should have a leading short line summarizing the changes. For |
|
100 | Commit messages should have a leading short line summarizing the changes. For | |
94 | bug fixes, put "(Issue #123)" at the end of this line. |
|
101 | bug fixes, put "(Issue #123)" at the end of this line. | |
95 |
|
102 | |||
96 | Contributions will be accepted in most formats - such as pull requests on |
|
103 | Contributions will be accepted in most formats - such as pull requests on | |
97 | bitbucket, something hosted on your own Kallithea instance, or patches sent by |
|
104 | bitbucket, something hosted on your own Kallithea instance, or patches sent by | |
98 | mail to the kallithea-general mailing list. |
|
105 | mail to the kallithea-general mailing list. | |
99 |
|
106 | |||
100 | Make sure to test your changes both manually and with the automatic tests |
|
107 | Make sure to test your changes both manually and with the automatic tests | |
101 | before posting. |
|
108 | before posting. | |
102 |
|
109 | |||
103 | We care about quality and review and keeping a clean repository history. We |
|
110 | We care about quality and review and keeping a clean repository history. We | |
104 | might give feedback that requests polishing contributions until they are |
|
111 | might give feedback that requests polishing contributions until they are | |
105 | "perfect". We might also rebase and collapse and make minor adjustments to your |
|
112 | "perfect". We might also rebase and collapse and make minor adjustments to your | |
106 | changes when we apply them. |
|
113 | changes when we apply them. | |
107 |
|
114 | |||
108 | We try to make sure we have consensus on the direction the project is taking. |
|
115 | We try to make sure we have consensus on the direction the project is taking. | |
109 | Everything non-sensitive should be discussed in public - preferably on the |
|
116 | Everything non-sensitive should be discussed in public - preferably on the | |
110 | mailing list. We aim at having all non-trivial changes reviewed by at least |
|
117 | mailing list. We aim at having all non-trivial changes reviewed by at least | |
111 | one other core developer before pushing. Obvious non-controversial changes will |
|
118 | one other core developer before pushing. Obvious non-controversial changes will | |
112 | be handled more casually. |
|
119 | be handled more casually. | |
113 |
|
120 | |||
114 | For now we just have one official branch ("default") and will keep it so stable |
|
121 | For now we just have one official branch ("default") and will keep it so stable | |
115 | that it can be (and is) used in production. Experimental changes should live |
|
122 | that it can be (and is) used in production. Experimental changes should live | |
116 | elsewhere (for example in a pull request) until they are ready. |
|
123 | elsewhere (for example in a pull request) until they are ready. | |
117 |
|
124 | |||
118 |
|
125 | |||
119 | "Roadmap" |
|
126 | "Roadmap" | |
120 | --------- |
|
127 | --------- | |
121 |
|
128 | |||
122 | We do not have a road map but are waiting for your contributions. Here are some |
|
129 | We do not have a road map but are waiting for your contributions. Here are some | |
123 | ideas of places we might want to go - contributions in these areas are very |
|
130 | ideas of places we might want to go - contributions in these areas are very | |
124 | welcome: |
|
131 | welcome: | |
125 |
|
132 | |||
126 | * Front end: |
|
133 | * Front end: | |
127 | * kill YUI - more jQuery |
|
134 | * kill YUI - more jQuery | |
128 | * remove other dependencies - especially the embedded cut'n'pasted ones |
|
135 | * remove other dependencies - especially the embedded cut'n'pasted ones | |
129 | * remove hardcoded styling in templates, make markup more semantic while moving all styling to css |
|
136 | * remove hardcoded styling in templates, make markup more semantic while moving all styling to css | |
130 | * switch to bootstrap or some other modern UI library and cleanup of style.css and contextbar.css |
|
137 | * switch to bootstrap or some other modern UI library and cleanup of style.css and contextbar.css | |
131 | * new fancy style that looks good |
|
138 | * new fancy style that looks good | |
132 | * testing |
|
139 | * testing | |
133 | * better test coverage with the existing high level test framework |
|
140 | * better test coverage with the existing high level test framework | |
134 | * test even more high level and javascript - selenium/robot and splinter seems like the top candidates |
|
141 | * test even more high level and javascript - selenium/robot and splinter seems like the top candidates | |
135 | * more unit testing |
|
142 | * more unit testing | |
136 | * code cleanup |
|
143 | * code cleanup | |
137 | * move code from templates to controllers and from controllers to libs or models |
|
144 | * move code from templates to controllers and from controllers to libs or models | |
138 | * more best practice for web apps and the frameworks |
|
145 | * more best practice for web apps and the frameworks | |
139 | * features |
|
146 | * features | |
140 | * relax dependency version requirements after thorough testing |
|
147 | * relax dependency version requirements after thorough testing | |
141 | * support for evolve |
|
148 | * support for evolve | |
142 | * updates of PRs ... while preserving history and comment context |
|
149 | * updates of PRs ... while preserving history and comment context | |
143 | * auto pr merge/rebase |
|
150 | * auto pr merge/rebase | |
144 | * ssh |
|
151 | * ssh | |
145 | * bitbucket compatible wiki |
|
152 | * bitbucket compatible wiki | |
146 | * realtime preview / wysiwyg when editing comments and files |
|
153 | * realtime preview / wysiwyg when editing comments and files | |
147 | * make journal more useful - filtering on branches and files |
|
154 | * make journal more useful - filtering on branches and files | |
148 | * community mode with self registration and personal space |
|
155 | * community mode with self registration and personal space | |
149 | * improve documentation |
|
156 | * improve documentation | |
150 |
|
157 | |||
151 | Thank you for your contribution! |
|
158 | Thank you for your contribution! | |
152 | -------------------------------- |
|
159 | -------------------------------- | |
153 |
|
160 | |||
154 |
|
161 | |||
155 | .. _Weblate: http://weblate.org/ |
|
162 | .. _Weblate: http://weblate.org/ | |
156 | .. _Issue Tracker: https://bitbucket.org/conservancy/kallithea/issues?status=new&status=open |
|
163 | .. _Issue Tracker: https://bitbucket.org/conservancy/kallithea/issues?status=new&status=open | |
157 | .. _Pull Requests: https://bitbucket.org/conservancy/kallithea/pull-requests |
|
164 | .. _Pull Requests: https://bitbucket.org/conservancy/kallithea/pull-requests | |
158 | .. _bitbucket: http://bitbucket.org/ |
|
165 | .. _bitbucket: http://bitbucket.org/ | |
159 | .. _mailing list: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general |
|
166 | .. _mailing list: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general | |
160 | .. _Hosted Weblate: https://hosted.weblate.org/projects/kallithea/kallithea/ |
|
167 | .. _Hosted Weblate: https://hosted.weblate.org/projects/kallithea/kallithea/ |
General Comments 0
You need to be logged in to leave comments.
Login now