1 |
Bircoph: |
2 |
mgorny has worked with infra to get something that is suitable. |
3 |
_ANY_ CI is an improvement over no CI. |
4 |
|
5 |
Our constraints are: |
6 |
- Should interoperate via a NON-GitHub-specific Webhook trigger |
7 |
- Yes, per my prior email to lists, we can send a notification to |
8 |
anything that can take incoming webhooks. |
9 |
- Should NOT pollute the repository with service-specific files. |
10 |
- No .travis.yaml file |
11 |
- No wercker/ directory |
12 |
- No circle.yml file |
13 |
- Should either be entirely self-contained, or use external resources. |
14 |
- Infra doesn't have the resources (manpower or hardware) to |
15 |
individually manage every single CI testsuite environment, and QA |
16 |
has a MUCH better idea of what they want to test. |
17 |
- Travis-CI etc are GOOD for this case, because it allows us to focus |
18 |
limited manpower on the content of the testcases, rather than the |
19 |
environment to run them in. |
20 |
- If you could give infra a Docker container that say runs a webserver, |
21 |
and accepts a WebHook call at http://.../webhook then does USEFUL |
22 |
work and emails or does a HTTP POST of the result; and YOU are |
23 |
willing to maintain the container definition, then we'll find |
24 |
somewhere good to run it (should not be dependant on IPv4 |
25 |
connectivity, you might get a v6-only environment). |
26 |
Look at what Wercker is doing to speed up CI using containers, it shows a |
27 |
lot of promise as a concept. |
28 |
|
29 |
> If travis will become essential for Gentoo development, it may |
30 |
> undermine development freedom and Gentoo social contract, which |
31 |
> states: "Gentoo will never depend upon a piece of software or metadata |
32 |
> unless it conforms to the GNU General Public License, the GNU Lesser |
33 |
> General Public License, the Creative Commons - Attribution/Share Alike |
34 |
> or some other license approved by the Open Source Initiative (OSI)." |
35 |
This argument has come up before, claiming that something one team is |
36 |
doing isn't in line with the social contract. mgorny himself complained |
37 |
about infra's repos being non-public. |
38 |
|
39 |
Let's expand that section somewhat, from the original text: |
40 |
"We will release our contributions to Gentoo as free software, metadata or |
41 |
documentation, under the GNU General Public License version 2 or the Creative |
42 |
Commons - Attribution / Share Alike version 2. ... However, Gentoo will never |
43 |
depend upon a piece of software or metadata unless it conforms to the GNU |
44 |
General Public License, the GNU Lesser General Public License, the Creative |
45 |
Commons - Attribution/Share Alike or some other license approved by the Open |
46 |
Source Initiative." |
47 |
|
48 |
I'm going to use the word 'libre' below, to differentiate between a |
49 |
'free-as-in-freedom' license, and the 'free-as-in-beer' offering from |
50 |
commerical CI providers. |
51 |
|
52 |
Infra's repo contents are licensed libre: most scripts I've written in the |
53 |
infra repos carry a BSD license, in many cases because I wrote them for dayjob |
54 |
purposes first, and later modified them for Gentoo. |
55 |
|
56 |
We can expand this, by stating that the repos we want to test with CI must |
57 |
remain libre. |
58 |
|
59 |
It says NOTHING about the CI tools themselves. Why should we not be able to |
60 |
benefit from really good closed-source CI tools that are offered for free to |
61 |
the open-source community? As long as we can continue to function WITHOUT those |
62 |
tools, there is no direct harm [1] done in using them. They cannot force us to |
63 |
change the licenses of our repos at all. |
64 |
|
65 |
> Travis itself is a closed, proprietary and non-trivial-to-replace |
66 |
> solution. |
67 |
If our CI testsuite contents are libre licensed (QA is running pcheck, which |
68 |
is again suitably licensed), and Travis-CI or whichever CI service suddenly |
69 |
because Evil(TM), there is nothing stopping us from running our testsuite |
70 |
elsewhere. All that remains is hooking the testsuite into the CI service. |
71 |
|
72 |
[1] I state direct harm here. You're going to argument that it affects the |
73 |
ecosystem, by discouraging other services. Jenkins, Buildbot and others are |
74 |
existing libre options in this ecosystem, but aren't keeping pace with |
75 |
development. |
76 |
|
77 |
|
78 |
-- |
79 |
Robin Hugh Johnson |
80 |
Gentoo Linux: Developer, Infrastructure Lead |
81 |
E-Mail : robbat2@g.o |
82 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |