Merge lp:~junrrein/granite/developer-documentation into lp:~elementary-pantheon/granite/granite

Proposed by Julián Unrrein
Status: Merged
Approved by: xapantu
Approved revision: 608
Merged at revision: 863
Proposed branch: lp:~junrrein/granite/developer-documentation
Merge into: lp:~elementary-pantheon/granite/granite
Diff against target: 147 lines (+143/-0)
1 file modified
HACKING (+143/-0)
To merge this branch: bzr merge lp:~junrrein/granite/developer-documentation
Reviewer Review Type Date Requested Status
xapantu (community) Approve
David Gomes Pending
Review via email: mp+180705@code.launchpad.net

Commit message

Add developer documentation.

Description of the change

Add developer documentation about how to contribute to Granite.

To post a comment you must log in.
608. By Julián Unrrein

Include option to generate debug symbols in configuration step.

Revision history for this message
David Gomes (davidgomes) wrote :

Claimed the review, I got this for tomorrow.

Revision history for this message
xapantu (xapantu) wrote :

That would be better if it was a normal markdown file, but still, that's an improvement. Thanks :)

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file 'HACKING'
2--- HACKING 1970-01-01 00:00:00 +0000
3+++ HACKING 2013-08-17 21:42:16 +0000
4@@ -0,0 +1,143 @@
5+====== Granite - Contribute ======
6+
7+This document is licensed under the LGPL 2.1.
8+
9+====== Testing the latest build ======
10+
11+Get daily builds in Launchpad (https://launchpad.net/~elementary-os/+archive/daily ppa:elementary-os/daily).
12+
13+====== Join IRC chat rooms ======
14+
15+Join #elementary-dev on Freenode: https://kiwiirc.com/client/irc.freenode.net/elementary-dev.
16+
17+====== Contribute without touching code ======
18+
19+- http://bugs.launchpad.net/granite Go through problem reports and check Unconfirmed bugs or those lacking information and mark any duplicates you spot.
20+- https://translations.launchpad.net/granite Help getting Granite translated in your language!
21+
22+====== Check out the sources ======
23+
24+ bzr branch lp:granite
25+
26+The development trunk (master, tip) is the latest iteration of the next release.
27+Browse it online and look for other branches at http://code.launchpad.net/granite
28+
29+====== Build the code ======
30+
31+ mkdir build
32+ cd build
33+ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ..
34+ make
35+
36+Run a program using your compiled Granite branch:
37+ LD_LIBRARY_PATH=/home/USERNAME/granite/build/lib program
38+
39+To compile a program using your compiled Granite branch, you will need to install it:
40+ sudo make install
41+
42+====== Coding style and quality ======
43+
44+Check the official elementary Code Style guide at:
45+ http://elementaryos.org/docs/code/code-style
46+
47+====== Important: Keep fixes for different bugs in different branches ======
48+
49+Branches that contain patches to fix more than one bug will be rejected, and you will be asked to supply a separate branch for every bug fix.
50+This doesn't apply to patches that are indivisible by nature, and that fix multiple bugs.
51+
52+The reasons to work in this way are the following:
53+
54+ * If one of the bugs targeted by your branch is correctly fixed, but one of the other bugs is incorrectly fixed or needs corrections, the branch won't be accepted until everything looks ok for all bugs. This causes an unnecessary delay for the bugs that where fixed correctly.
55+ * Suppose your branch was accepted for merging in the main one. Later, it is discovered that your branch introduces faulty behavior. The standard course of action for these situations is to revert the merge that introduced that faulty behavior. This will cause that all of your fixes are reverted (even the ones that didn't cause problems) because there was no way of discriminating between them. If a separate branch for each bug fixed existed, only the offending one would have been reverted, and not all of them.
56+
57+Be sure to understand this, and avoid a headache later!
58+
59+====== Committing code ======
60+
61+Make a branch which will contain your changes for fixing bug XXXX:
62+ bzr branch lp:granite fix-XXXX
63+
64+Tell Bazaar your name if you haven't yet:
65+ bzr whoami "Real Name <email@address>"
66+
67+See what you did so far:
68+ bzr diff
69+ bzr diff | colordiff
70+
71+Get an overview of changed and new files:
72+ bzr status
73+
74+Add new files, move/ rename or delete:
75+ bzr add FILENAME
76+ bzr mv OLDFILE NEWFILE
77+ bzr rm FILENAME
78+
79+After making your changes, you need to commit your work as a new revision.
80+ bzr commit -m "Commit message"
81+
82+Commit your changes in small increments. It is better to keep different changes in different commits.
83+
84+To see the last 5 revisions in the current branch:
85+ bzr log -l5
86+ bzr log -l5 -p | less
87+
88+In the case you committed something wrong or want to ammend it:
89+ bzr uncommit
90+
91+If you want to revert all the changes made after the last revision:
92+ bzr revert
93+
94+Remember to keep your branch updated:
95+ bzr pull
96+
97+As a general rule of thumb, ''bzr help COMMAND'' gives you an explanation of any command and ''bzr help commands'' lists all available commands.
98+
99+====== Push proposed changes ======
100+
101+If you haven't yet, https://launchpad.net/~/+editsshkeys check that Launchpad has your SSH key - you can create an SSH key with Passwords and Keys aka Seahorse or ''ssh-keygen -t rsa'' - and use ''bzr launchpad-login'' to make youself known to bzr locally.
102+
103+If you checked out trunk, and added your patch(es), just push it under your username in Launchpad and you can propose it for merging into trunk. This will automatically request a review from other developers who can then comment on it and provide feedback.
104+
105+ bzr push lp:~USERNAME/granite/fix-123456
106+ bzr lp-open
107+
108+The last command will open a summary of the current branch in your web browser. There, you will be able to propose it for merging into trunk.
109+Your branch will be reviewed by another developer. At this stage, you may be notified that changes need to be made to your branch, so keep an eye on your email inbox!
110+After the branch is approved by the reviewer, it will get merged into the main project's source code.
111+
112+
113+What happens to all the branches?
114+
115+Leave the branches alone, approved branches are cleared automatically by Launchpad.
116+
117+For larger feature branches, use the team in Launchpad to allow other developers to work on the code with you.
118+
119+
120+What if I want to help out on an existing merge request that I can't push to?
121+
122+ bzr branch ~OTHERPERSON/granite/fix-123456
123+ cd fix-123456
124+ # make commits
125+ bzr push lp:USERNAME~/midori/fix-123456
126+ bzr lp-open
127+
128+And in the Launchpad web overview of your branch, propose your branch for merging into ~OTHERPERSON/granite/fix-123456
129+
130+
131+Updating a branch that may be out of sync with trunk:
132+
133+ bzr pull
134+ bzr: ERROR: These branches have diverged
135+ bzr merge lp:granite
136+ # Hand-edit conflicting changes
137+ bzr resolve FILENAME
138+ # If any conflicts remain continue fixing
139+ bzr commit -m 'Merge changes from lp:granite'
140+
141+
142+Save a little bandwidth, branch from an existing local copy that you keep around:
143+
144+ bzr branch lp:granite granite
145+ bzr branch granite/ granite-fix-123456
146+ cd granite-fix-123456
147+ bzr pull lp:granite

Subscribers

People subscribed via source and target branches