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 |