aboutsummaryrefslogtreecommitdiff
path: root/contribution.texi
blob: 679683cf1afe0d38bb23e6342d4915ab42e8a329 (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
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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
@macro contid{id}
[@anchor{\id\}\id\]
@end macro

@macro sectid{id, sect}
@strong{@contid{\id\} \sect\}
@end macro

@node Contribution Guidelines
@chapter Contribution Guidelines

Thanks for taking your time to contribute! To maintain stylistic behaviour
throughout the repositories, one must adhere to these conventions. Exceptions
and changes may occur with good reasoning.

@menu
* Conventions::
* Sending Git mails::
@end menu

@node Conventions
@section Conventions

@node General Conventions
@subsection General Conventions -- 00

@table @strong
@item @contid{0010}
Try to keep the file readable.
@table @strong
@item @contid{0011}
Characters on a line shouldn't exceed 100 characters.
@item @contid{0012}
Make sure you don't have code commented out during commit. Uncomment them
or remove them completely.
@item @contid{0013}
Do not add comments following the code, add them to the top of the code. It
makes it harder to read, and lines longer. Here is an example:
@example
# Good way of commenting.
your code goes here

your code goes here  # Avoid this way of commenting.
@end example
@end table
@end table

@node Shell Conventions
@subsection Shell Conventions -- 10

Shell is central to Carbs Linux projects. Most of the tools and packages are
written in POSIX sh.

@table @strong
@item @contid{1010}
Use 4 spaces for indentation, don't use tabs.
@item @contid{1020}
Make sure you don't use bash-specific code.
@item @contid{1030}
Make sure you lint your code with @command{shellcheck} and if you are new to
POSIX sh, use @command{checkbashisms}.
@item @contid{1040}
Don't spawn new processes if you don't absolutely need to, especially during
string manipulation.
@table @strong
@item @contid{1041}
Never use a program for text manupilation that isn't defined in the POSIX
standard. This includes @command{gawk} and @command{perl}.
@item @contid{1042}
Instead of @code{$(basename $file)}, use @code{$@{file##*@}}.
@item @contid{1043}
Instead of @code{$(dirname $file)}, use @code{$@{file%/*@}}.
@end table
@example
# This is the same thing as @code{basename /path/to/test.asc .asc}

$ file=/path/to/test.asc file=$@{file##*/@} file=$@{file%.asc@}
$ echo $file
test
@end example
@item @contid{1050}
Instead of backticks, use @verb{|$(..)|}.
@end table

@node Repository Conventions
@subsection Repository Conventions -- 20

Repository conventions are important in order to ensure every package resemble
themselves. Here are the things to keep in mind:

@table @strong
@item @contid{2010}
Prefer tarballs over git packages unless there is a sensible reason.
Here are some:

@itemize
@item
Every patch is a new release. (See @url{https://github.com/vim/vim, vim})
@item
There are no releases. (See @url{https://git.suckless.org/sbase})
@item
Following a development branch.
@item
There has been a long time since the latest release, but upstream is far ahead.
@end itemize

@item @contid{2020}
Prefer sources without a dependency to @command{automake}. There are usually
distribution tarballs that are @command{autoconf}'ed. Don't submit tarballs
with an automake dependency unless you are @strong{sure} there is no
alternative.
@item @contid{2030}
Avoid these packages:
@table @command
@item dbus
Usually can be disabled by @option{--disable-dbus}
@item gettext
Usually can be disabled by @option{--disable-nls}
@end table
@item @contid{2040}
@itemize
@item
Always install a package to the @file{/usr} prefix.
@item
All binaries should go to @file{/usr/bin}, not @file{/usr/sbin} or any other
directory.
@item
All libraries should go to @file{/usr/lib}.
@end itemize
@item @contid{2050}
All build files on the repository should be a POSIX shell script, and must start
with @code{#!/bin/sh -e}.
@end table

The next section is about package templates that should be used in order to
ensure stylistic consistency. Note that the option configurations shouldn't be
taken literally, they are meant as examples.

@sectid{2210, Make}

@example
#!/bin/sh -e

make
make DESTDIR="$1" PREFIX=/usr install
@end example

@sectid{2211, Configure/Make}

@example
#!/bin/sh -e

./configure \
    --prefix=/usr \
    --disable-option \
    --enable-option

make
make DESTDIR="$1" install
@end example


@sectid{2212, Autoconf/Automake}

@xref{2020}

@example
#!/bin/sh -e

autoreconf -fi

./configure \
    --prefix=/usr \
    --disable-option \
    --enable-option

make
make DESTDIR="$1" install
@end example

@sectid{2220, Meson}

@example
#!/bin/sh -e

export DESTDIR=$1

meson \
    --prefix=/usr \
    -Doption=false \
    -Doption2=true \
    . output

ninja -C output
ninja -C output install
@end example

@sectid{2230, Cmake}

@example
#!/bin/sh -e

export DESTDIR=$1

cmake -B build \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_BUILD_TYPE=Release \
    -DOPTION=ON

cmake --build   build
cmake --install build
@end example

@sectid{2240, Go}

@example
#!/bin/sh -e

export GOPATH=$PWD/gopath
trap "go clean -modcache" EXIT INT
go mod vendor

go build
install -Dm755 program "$1/usr/bin/program"
@end example

@sectid{2241, Python}

@example
#!/bin/sh -e

python setup.py build
python setup.py install --prefix=/usr --root="$1"
@end example

@node Sending Git mails
@section Sending Git mails

As mentioned, the preferred way of contribution is via patches. The easiest way
for sending git mails without @command{git send-email} is using @command{msmtp}.
You can install it from the repository by doing:

@example
$ cpt b msmtp && cpt i msmtp
@end example

You can then edit @file{~/.config/msmtp/config} to add your email. Here is an
example configuration, you can use @command{pass}, @command{pash}, or any other
password manager that fits your needs:

@example
defaults
auth on
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.config/msmtp/msmtp.log
account my-mail
host mail.example.com
port 587
from me@@example.com
user me@@example.com
passwordeval "pass my-mail"
@end example

In order to simply send your patch, do the following:

@example
$ git format-patch --to=~carbslinux/dev+subscribe@@lists.sr.ht -1 --stdout |
    msmtp -t -a my-mail
@end example

You can also send multiple patches by doing the following:

@example
$ git format-patch --to=~carbslinux/dev+subscribe@@lists.sr.ht <region>

Edit those files as necessary and send them.
$ for file in *.patch; do msmtp -t -a my-mail < $patch; done
@end example