|
Lines 23-29
Link Here
|
| 23 |
however that all developers maintain reasonable standards of behaviour |
23 |
however that all developers maintain reasonable standards of behaviour |
| 24 |
with our community - whether to other developers or users. However, |
24 |
with our community - whether to other developers or users. However, |
| 25 |
you may be subject to sanctions or a suspension if a resonable |
25 |
you may be subject to sanctions or a suspension if a resonable |
| 26 |
standard is not. |
26 |
standard is not met. |
| 27 |
</p> |
27 |
</p> |
| 28 |
|
28 |
|
| 29 |
<p> |
29 |
<p> |
|
Lines 80-87
Link Here
|
| 80 |
<ul> |
80 |
<ul> |
| 81 |
<li> |
81 |
<li> |
| 82 |
Make your ChangeLogs readable to the average end-user: try to keep |
82 |
Make your ChangeLogs readable to the average end-user: try to keep |
| 83 |
things simple and short if you can but provide any critical |
83 |
things simple and short if you can, but provide any critical |
| 84 |
information if you need to. Remember that ChangeLogs need to be |
84 |
information as needed. Remember that ChangeLogs need to be |
| 85 |
written in good, "correct" English even if they are |
85 |
written in good, "correct" English even if they are |
| 86 |
short. Punctuation is essential. |
86 |
short. Punctuation is essential. |
| 87 |
</li> |
87 |
</li> |
|
Lines 132-147
Link Here
|
| 132 |
<li> |
132 |
<li> |
| 133 |
Try to not bump ebuilds continuously unless there really <b>is</b> a |
133 |
Try to not bump ebuilds continuously unless there really <b>is</b> a |
| 134 |
benefit or a security fix which is important. Unnecessary examples |
134 |
benefit or a security fix which is important. Unnecessary examples |
| 135 |
of bumping include situations where a patch for the support of a |
135 |
of bumping include: |
| 136 |
new kernel version is added, for example; unless the ebuild is out |
136 |
<ul> |
| 137 |
of date from the date of the bug report. |
137 |
<li> |
| 138 |
</li> |
138 |
You change minor spelling errors in script file comments, script file |
| 139 |
<li> |
139 |
indentation or similar. |
| 140 |
Try to not make ebuilds do unnecessary steps or do things outside of |
140 |
</li> |
| 141 |
the package which may be un-needed: packaging unsupported |
141 |
<li> |
| 142 |
patches as an "addition" is a bad idea unless they are either |
142 |
You patch your non-kernel ebuild to support a new kernel version (or |
| 143 |
tested well by both you and your target audience and that they |
143 |
a new version of a library), allowing more users to install your ebuild, |
| 144 |
are code-checked for security. |
144 |
but not changing anything for existing users of the current revision. |
|
|
145 |
</li> |
| 146 |
</ul> |
| 147 |
As a general rule, fixes with non-trivial changes to any of the installed |
| 148 |
files of any ebuild warrant a revision bump. Put differently: If your fix |
| 149 |
changes the behaviour for existing users, you bump so that they will |
| 150 |
upgrade. |
| 151 |
</li> |
| 152 |
<li> |
| 153 |
Try to not make ebuilds preform unnecessary steps. Packaging unsupported |
| 154 |
patches unsupported patches as an "addition" is a bad idea unless they |
| 155 |
are thoroughly tested by you, widely used, and audited for security |
| 156 |
vulnerabilities. |
| 145 |
</li> |
157 |
</li> |
| 146 |
<li> |
158 |
<li> |
| 147 |
Ebuilds should be well commented if non-standard code or large |
159 |
Ebuilds should be well commented if non-standard code or large |
|
Lines 151-161
Link Here
|
| 151 |
don't shower the user with a stream of information. |
163 |
don't shower the user with a stream of information. |
| 152 |
</li> |
164 |
</li> |
| 153 |
<li> |
165 |
<li> |
| 154 |
Respect developers' coding preferences and don't change the |
166 |
Respect developers' coding preferences. Unneccessarily changing the syntax |
| 155 |
ebuild syntax to remove stress on the CVS server, and to make |
167 |
of an ebuild increases the load on the CVS server and can cause complications |
| 156 |
things simpler for everybody unless you feel there is a real |
168 |
for others. Syntax changes should only be done if there is a real benefit, |
| 157 |
benefit in adding syntax cleanups - for example, faster |
169 |
such as faster compilation or improved information for the end user. |
| 158 |
compilation or a better more verbose output to the end-user. |
|
|
| 159 |
</li> |
170 |
</li> |
| 160 |
</ul> |
171 |
</ul> |
| 161 |
|
172 |
|
