1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
====== Contribute ======
This document is licensed under the GPL 3.
====== Testing the latest build ======
Get daily builds in Launchpad (https://launchpad.net/~elementary-os/+archive/daily ppa:elementary-os/daily).
====== Join IRC chat rooms ======
Join #elementary-dev on Freenode: https://kiwiirc.com/client/irc.freenode.net/elementary-dev.
====== Contribute without touching code ======
- http://bugs.launchpad.net/eutility Go through problem reports and check Unconfirmed bugs or those lacking information and mark any duplicates you spot.
- https://translations.launchpad.net/eutility Help getting this plug translated in your language!
====== Check out the sources ======
bzr branch lp:power-installer
The development trunk (master, tip) is the latest iteration of the next release.
Browse it online and look for other branches at http://code.launchpad.net/eutility
====== Build the code ======
Refer to INSTALL for required dependencies.
Then:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make
sudo make install
Run Power Installer:
power-installer
====== Debugging issues ======
Testing an installed release may reveal crashers or memory corruption which require investigating from a local build and obtaining a stacktrace (backtrace, crash log).
gdb ./power-installer
====== Coding style and quality ======
Check the official elementary Code Style guide at:
http://elementaryos.org/docs/code/code-style
====== Important: Keep fixes for different bugs in different branches ======
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.
This doesn't apply to patches that are indivisible by nature, and that fix multiple bugs.
The reasons to work in this way are the following:
* 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.
* 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.
Be sure to understand this, and avoid a headache later!
|