diff options
| -rw-r--r-- | README | 48 |
1 files changed, 47 insertions, 1 deletions
@@ -48,7 +48,7 @@ you can now simply launch `poezio' You can edit the config file (~/.config/poezio/poezio.cfg by default) or data/default_config.cfg (if you want to edit the config before the -first launch). The default config file is fully commented. +first launch). The default config file is fully commented. Please, see the online documentation for more information on installing, configuring or using poezio: @@ -85,6 +85,52 @@ Please read the COPYING file for details. The artwork logo was made by Gaëtan Ribémont and released under the Creative Commons BY license (http://creativecommons.org/licenses/by/2.0/) + +======================= + Hacking +======================= +If you want to contribute, you are invited on poezio@muc.poezio.eu to +announce your ideas, what you are going to do, or to seek help if you +have trouble understanding some of the code. +The preferred way to submit changes is through a public git repository. +But mercurial repositories or simple patches are also welcome. + +For contributors having commit access: + +This section explains how the git repository is organized. +The “master” branch is the branch where all recent development is made. This is +the unstable version, which can be broken, but we should try to keep it usable +and crash-free as much as possible (so, never push to it if you are adding a +*known* crash). + +New big features that take time to be complete should be developped in feature +branches (for example the “plugins” or the “opt” branches). +If it’s a really long feature, merge the “master” branch in that feature branch +from time to time, to avoid huge merges (and merge issues) when you’ll have to +merge your feature back in “master”. +Merge your work in master once it works and is usable, not necessarily when +it’s 100% finished. Polishing and last bug fixes can take place in “master”. + +Conflicts should be solved with *rebase* and not with merge. This means +that if two developpers commited one thing at the same time in their own +repository, the first pushes on the public public repos, and the other +has to pull before being able to push too. In that case, the second +developper should use the rebase command instead of merge. This avoids +creating unnecessary “branches” and visible merges. +On the contrary, when merging feature branches back to “master”, we should +use merge with the --no-ff tag (this makes sure the branch will always +distinctly appear in the logs), even if no conflict occured. + +Finally, when a release is ready, we should merge the “master” branch +into the releases branch, then tag it to that version number. +If an “urgent” bugfix has to be made for a release (for example +a security issue is discovered on the last stable version, and +the current master has evolved too much to be released in the current +state), we create a new bugfix branch from the “releases” branch, we fix +it and finally merge it back to the “releases” branch, and tag it (and +we merge it to “master” as well, of course). + + ======================= Thanks ======================= |