blob: 5791b3efae6495d7ec0f9131683d944b50254796 (
plain)
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
|
WHAT RULES I SHOULD FOLLOW WHEN I WANT WORK ON SOMETHING FOR KDE TEAM?
If you asked this question you are reading right file.
So the rules are these:
- always use kde4-* eclasses
- always report cmake issues about everything directly to upstream and backport their fix
- never use -j1 in ebuilds. Always report the issue upstream and wait for the resolution or fix yourself
- doubleckeck the doc useflag in your package
- think about adding debug useflag to your package
- always check for linguas and add them to the KDE_LINGUAS variable
- always fix automagic packages with macro_optional_ prefixing and report it upstream with patch.
- check your apps deps with dylink scanner in maintainer folder
- if you want our herd in the application and you are not kde team HT/Member ask us first
- if you create blocker make sure it is in RDEPEND and comment the reason why you created the blocker
the blocker must contain specific version for the block
ie. we introduce blocker for 4.1.87 then we add to the block !<cat/pn-4.1.87
remember to use correct +-kdeprefix resolution
!kdeprefix? ( !<cat/pn-version[kdeprefix-] )
kdeprefix? ( !<cat/pn-version:slot[kdeprefix] )
Commiting:
- All commit messages must look like this:
category/pn - Message describing what i did
kde-base/kdelibs - sync with main tree.
- When you commit something for some bug add inOverlay to keywords, so normal devs know about it
also add [overlay-name] to the summary
KDE 3:
- do what ever you want with one condition, make sure it really compiles/run
- feel free to commit patches without kde team ack if the above condition is checked
# NOT FOLLOWING THIS RULES WILL BE PUNISHED!
# no cookies for week!
|
