DeveloperGuide » History » Version 2
Paul Kocialkowski, 12/21/2012 06:22 PM
1 | 1 | Paul Kocialkowski | h1. Developer Guide |
---|---|---|---|
2 | |||
3 | These are guidelines that should be followed when doing Replicant development. |
||
4 | |||
5 | h2. Repositories |
||
6 | |||
7 | When working with Replicant repos, make sure to avoid breaking things. For instance, if you push a commit introducing a compilation error, it will break the whole build process. |
||
8 | It is better to create separate branches (that are not used by the official manifest branches) when your work is still in progress. |
||
9 | Creating branches that add debug infos on a particular topic is usually a good idea since it will save you time next time you want to debug the same component. |
||
10 | |||
11 | h3. When creating a repository |
||
12 | |||
13 | In order to keep repo naming consistent, please name repositories by their name on the tree, replacing the @/@ by @_@. |
||
14 | For instance, when forking the CyanogenMod repo: @android_device_samsung_crespo@, rename it to @device_samsung_crespo@ on the Replicant repos. |
||
15 | This creates a more consistent way of naming repositories and makes it easier when pushing: just look at the location in the source tree and replace @/@ by @_@. |
||
16 | |||
17 | h3. When creating a branch |
||
18 | |||
19 | Official replicant branches are named the following way: |
||
20 | * The @replicant-@ prefix |
||
21 | * The Replicant version |
||
22 | |||
23 | Such as: @replicant-2.3@ This should be used on the projects repositories as well as the manifest repository. |
||
24 | Any other branch should be considered as Work In Progress (WIP) and thus not be part of any official branch of the manifest. |
||
25 | |||
26 | There is although one exception, with the @master@ branch, that can be used by any project and be in any manifest given that the code held in the @master@ branch will work on any Replicant version. |
||
27 | 2 | Paul Kocialkowski | |
28 | h2. Upstreaming work |
||
29 | |||
30 | It is generally a good idea to send some changes back to upstream, assuming that they will benefit from it as well. |
||
31 | |||
32 | When it is about the replacement of a non-free component present in the upstream systems, make sure that your replacement is reliable and complete. |
||
33 | Contact the interested developers on the upstream projects before attempting to send your replacement. |
||
34 | |||
35 | h3. CyanogenMod |
||
36 | |||
37 | The CyanogenMod team uses Gerrit to manage patch submissions. The process to get your patch included in CyanogenMod repos is explained on their wiki: "Howto:Gerrit":http://wiki.cyanogenmod.org/wiki/Howto:_Gerrit |