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