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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
===========================================================================
1. Naming Rules
===========================================================================
1-1. "building-blocks" should be the first prefix.
1-2. The top-single block name is "building-blocks"
1-3. Level prefix = "root" | "sub1" | "sub2"
1-4. Except for the top-single block, Level prfix follows
the first prefix.
E.g., "building-blocks-sub1-..."
1-5. For "root" building blocks, the naming rule is:
[first prefix = "building-blocks"]-[level prefix = "root"]-[NAME]
E.g., "building-blocks-root-UI"
1-6. For "sub1" building blocks, which has a "root" building block, "ROOTNAME" as its parent, the naming rule is:
[first prefix]-[level prefix = "sub1"]-[root name = "ROOTNAME"]-[NAME]
E.g., "building-blocks-sub1-UI-wayland"
1-7. For "sub2" building blocks, which has a "sub1" building block, "SUB1NAME" as its parent, the naming rule is:
(SUB1NAME has ROOTNAME as its parent)
[first prefix]-[level prefix = "sub2"]-[root name = "ROOTNAME"]-[sub1 name = "SUB1NAME"]-[NAME]
E.g., "building-blocks-sub2-UI-wayland-core"
1-8. In order to implement "radio-button" UI (choose only one), the block name starts with "chooseonlyone_"
E.g., "building-blocks-root-chooseonlyone_Kernel"
#### CAUTION: NOT SUPPORTED. NOT GUARANTEED TO WORK AS SUPPOSED ####
1-9. [NAME] = [a-zA-Z0-9_]+
===========================================================================
2. Relations between blocks
===========================================================================
2-1. Top block (building-blocks) lists all root-level blocks
Lists with Suggests (optional) and Requires (mandatory)
2-2. A parent block lists all of its direct child blocks (no grandchild listed)
Lists with Suggests (optional) and Requires (mandatory)
2-3. A child block cannot have multiple parents.
2-4. Conflict may be defined between blocks.
However, you need to get consents from all related stake-holders.
2-6. There cannot be any other relations defined between blocks.
===========================================================================
3. Relations between a block and (non-block) packages
===========================================================================
3-1. A block may include non-block (individual) packages with Requires (mandatory) and Suggests (optional)
3-2. A package (not block) can exist in multiple blocks.
3-3. A package may be not included in any of the blocks
TIC UI will list such packages in "MISC" section.
===========================================================================
4. Maintainer and Review Rules
===========================================================================
4-1. Multiple maintainers (M:) per domain is possible. (limit = 3)
4-2. At least one maintainer per domain
4-3. Please do review in a week for incoming commits after review entry added for the maintainers
4-4. To comitters: add proper maintainers as the reviewers in gerrit.
===========================================================================
5. Other Coding Rules
===========================================================================
5-1. A domain cannot add "BuildRequires"
Global relations cannot be added by an individual domain.
5.2. A domain cannot add "Recommends", "Provides", "Enhances", "Supplements"
We do not have any semantics for building blocks with such relations.
When we have definitions for such semantics and have them implemented in
TIC, we can allow then.
5.3. A block must NOT have any files included
5.4. A block that is not preset/feature cannot add "Requires"/"Suggests" on
another block that is not a direct child of it
E.g., sub2-* cannot Requires/Suggests another root/sub1/sub2
E.g., sub1-A cannot Requires/Suggests sub2-B-X
|
