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
|
[[!meta title="Getting started with contributing to the project"]]
If you like ick or would like to contribute to help make it better, we
would love to have you join us!
This page has some suggestions for how to get started with that. Some
things are really easy, others will need more effort and commitment,
but you may well find a small thing to move the big thing further. How
much you want to do is your choice. You can contribute as little or as
much as you want.
First things
=============================================================================
You probably want to start with these kinds of things.
* Use ick. Set up instance for your own use. Report any problems in
the process, any missing information from documentation, any unclear
parts, anything that is inconvenient, etc.
* If you have access to the hardware, do some ick stress testing. Set
up an ick server with a very large number of workers, a very large
number of projects to build, and see if ick can handle that. Report
the problems. The unofficial wish is for Ick to handle 1000 worker
nodes building 1000 projects concurrently.
Documentation things
=============================================================================
* Read the ick website. Is anything confusing, weird, or looks wrong?
Can you spot the typo? Where should we insert a picture of kittens?
* Write, or outline, some user-oriented documentation. There is a
skeleton manual page for `icktool`, add to that. Write a completely
separate manual, either adding it to the ick source tree, or as a
completely separate project. If you don't know something, ask.
Development things
=============================================================================
* Build ick locally. Check out the source from git. There's no build
process (given it's in Python), but run the full test suite: run
`./check` at the top of the source code tree. This is especially
useful if you don't use Debian 9 (stretch) on the amd64
architecture. Report any issues.
* Review all the ick source code. Is anything confusing, weird, or
looks wrong?
* Read the ick
[[architecture]] document. Is
anything confusing, weird, or looks wrong? Do you get a feeling you
understand how ick is designed at a high level?
* Review any [[open tickets|issues]]. Is there any issue you can help
with?
* Review the Debian packaging of ick. Suggest improvements.
* Add packaging for other systems: Fedora, RHEL, OpenSuse, Gentoo,
Arch, CentOS; etc. Offer to maintain that in the future. Suggest
ways in which that could be done, and how the workflow should be.
* Make a web UI to do the equivalent of `icktool status` (a read-only
operation). Design a more powerful web UI that can do everything
you'd like to do with a CI system. (Read-write operations will need
to wait until ick gets a good IDP that supports web applications,
but that is happening.)
Advocacy things
=============================================================================
* Compare ick with other CI systems, such as Jenkins, BuildBot, go.cd,
Travis, GitLab CI, etc. How do they compare with ick? Write up a
short report. Or a long report, if you feel like it. (We don't
expect anyone to prefer ick at this stage.)
* Write a short article, long article, list of bullet point, on what
you personally would like to have in a CI or CD systems. Especially
useful if describe how ick would need to change for you to want to
start using it yourself.
|
