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
|
# Contributing Plugins
Contribution plugins that are not maintained by the thin-edge.io teams is
desired and encouraged.
This document describes the process of getting a "third party plugin" into the
thin-edge.io repository.
## Is this relevant for me?
This document is relevant for you if:
* You want to use thin-edge.io in your infrastructure, but...
* you need some custom functionality that you cannot (easily) add via the
interfaces exposed by thin-edge, for whatever reason
* You're willing to write Rust code to get your usecase covered with
thin-edge.io
If you can add a plugin via mechanisms exposed by thin-edge.io and you can
maintain that plugin outside of the codebase of thin-edge.io, this document is
**not** relevant for you!
## Developing the plugin
You're welcome to develop your plugin within the repository. To do that, you
have to follow these steps:
* Create your plugin on a new branch in the `/plugins` folder, using
`cargo new --lib`
* Implement your plugin and your business case
* Make sure that the code builds cleanly, to follow the coding styleguide
(`cargo fmt`), that there are no clippy warnings or errors, etc. Structure
your code cleanly. Do not use unsafe code, if possible
* If your development takes a long time, make sure to rebase your branch
frequently. If that is not possible, because a whole team is working on the
plugin and you have to merge forwards and backwards within your team, feel
free to contact us to discuss your workflow.
Once you're ready with your plugin, please propose it to us via a pull request.
If you're unsure about whether it meets our requirements for quality, feel free
to open a pull request anyways. If you open it as a draft, make sure to ping
someone, as we're not necessarily looking at draft pull requests!
The plugin will then be marked as "staging" plugin by us and be included IF it
meets our criteria for code quality and scope.
To not invest too much time without knowing whether we would take your plugin,
feel free to contact us early in your development cycle so we can discuss our
quality requirements etc.
## Plugin maintenance
If you propose a plugin and we merge it into the thin-edge.io codebase, you're
responsible for that plugin. That means that you continue development on that
plugin, you're allowed to approve pull requests for that plugin and you're
responsible for keeping the code up to date and free of bugs, to the best of
your knowledge.
For smaller fixes, the thin-edge.io team _might_ apply patches to your plugin.
Still, you will be consulted.
**Warning:** If we think you're not maintaining your plugin appropriately,
either by responding slowly, not following our community guidelines,
deliberately introduce bugs to our or your codebase, exploit other plugins in
any way, or for any other reason, we **can and will** remove your plugin at any
point in time we deem appropriate.
That said, we're of course always keen to have more contributions and plugin
authors in the project - we have to keep that possibility though and we hope you
understand that the above paragraph is necessary.
## Staging the plugin
Once we decide to merge your plugin, we will mark it as "staging". This means
that the plugin will be included in the release builds of thin-edge.io, but will
be gated with a special flag that a user must specify when running thin-edge, to
enable "staging" plugins.
The rationale for this is that we want to ship your plugin and make it available
to users, but also signal them that it might not be heavily tested just yet.
Once a plugin is out of that "staging" area, we expect it to be rock-solid _and_
battle tested.
As soon as we think that the plugin is decently tested, hopefully even in
production (by you?), we _can_ decide to "un-stage" your plugin. It will then be
integral part of the thin-edge.io project.
## Un-staging the plugin
To get your plugin out of the "staging" area, you can open an issue on our
repository and ask us to "un-stage" it.
Un-staging the plugin means that the thin-edge.io project now maintains the
plugin **with you**. This does **not** mean that you're free of your duty of
maintaining your plugin.
To get your plugin un-staged, the team will review your code, but also how you
develop and contribute to the project. Are you reasonably quick to respond? Are
you taking issues serious? Do you work with us in good faith and can we work
with you in good faith? You get the idea.
These points also mean that once you open a PR to add your (then staging)
plugin, you cannot expect us to un-stage your plugin right away once it is
merged. We have to gain some reasonable amount of trust in you to make your
plugin an integral part of thin-edge.io and that's what this process is for.
The above points may seem vague and not very on-point on when a plugin can be
un-staged - and that's intended. Trust cannot be earned by following a set of
rules.
|
