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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
===========================================================================
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" | "sub3"
However, using deep down to sub3 is not recommended (WARNING)
1-3-A. Using "sub3" is not recommended (WARNING)
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 "sub{N}" (N>1) building blocks, which has a "sub{N-1}" building block, "SUB{M}NAME" as its parent at level M (M < N), the naming rule is:
[first prefix]-sub{N}-[root name = "ROOTNAME"]-[sub1 name = "SUB1NAME"]-...-[sub{N-1} name = "SUB{N-1}NAME"]-[NAME]
E.g., "building-blocks-sub2-UI-wayland-core",
"building-blocks-sub3-UI-wayland-core-extension_super"
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.
Exception: preset and features blocks may Requires/Suggests
other blocks to populate themselves with higher readability.
Refer to RULE 5-4.
2.7. Do not refer to (or declare as a child) a block that does not exist
in this repository.
===========================================================================
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 (ref. RULE 2.6)
E.g., sub2-* cannot Requires/Suggests another root/sub1/sub2
E.g., sub1-A cannot Requires/Suggests sub2-B-X
5.5. A UI Block is a block that cannot be chosen or have relation with other blocks
or packages, but is used to provide UI elements in TIC.
5.5.1. A UI Block has the same naming rule with others.
5.5.2. A block becomes a UI block if it satisfies the following regex:
/__UI__..$/
5.5.3. The last two characters (.. in the regex above) are "tag" that consists of
the placement of the block.
5.5.3.1. Tags are:
BR or br: blank line
HR or hr: <hr>
SD or sd: shaded blank line
SM or sm: summary text is shown (HTML tags works)
HT or ht: HTML tags from summary text is used. (same with SM/sm...)
HF or hf: blank line with half height
QT or qt: blank line with quarter height
5.6. Blocks in TIC are placed sorted by package name. (ascending order)
5.7. If the first line of %description starts with __KS_URL__, it denotes for
the model ks file URL to be interpreted by TIC.
5.7.1. Only platform-Preset_boards/sd may use such keywords
5.7.2. Only one package with such keyword is effective. If there are two packages
with such keywords are chosen simultaneously, the behavior is "undefined".
5.7.3. The section of "%packages" in the linked ks file is ignored.
5.7.4. If the URL points to a directory index, any ks file in the directory can be
used. (ending with /)
5.7.5. Adding __KS_URL__ requires consulting building-block maintainers and
release engineers to ensure its availability.
5.8. If the first line of %description starts with __EXPAND__, the block is
expanded in TIC as default
5.8.1. A following word of __EXPAND__ may denote keywords for TIC that
show when to expand and collapse.
e.g., __EXPAND__: preset (expanded with preset tab)
e.g., __EXPAND__: all (expanded with all tab)
5.8.2. Using __EXPAND__ option requires consulting with building-block maintainers
5.8.3. Using __EXPAND__ is allowed only for root blocks
|
