Bircoph:
mgorny has worked with infra to get something that is suitable.
_ANY_ CI is an improvement over no CI.

Our constraints are:
- Should interoperate via a NON-GitHub-specific Webhook trigger
  - Yes, per my prior email to lists, we can send a notification to
        anything that can take incoming webhooks.
- Should NOT pollute the repository with service-specific files.
  - No .travis.yaml file
  - No wercker/ directory
  - No circle.yml file
- Should either be entirely self-contained, or use external resources.
  - Infra doesn't have the resources (manpower or hardware) to
        individually manage every single CI testsuite environment, and QA
        has a MUCH better idea of what they want to test.
  - Travis-CI etc are GOOD for this case, because it allows us to focus
        limited manpower on the content of the testcases, rather than the
        environment to run them in.
  - If you could give infra a Docker container that say runs a webserver,
        and accepts a WebHook call at http://.../webhook then does USEFUL 
    work and emails or does a HTTP POST of the result; and YOU are 
    willing to maintain the container definition, then we'll find 
    somewhere good to run it (should not be dependant on IPv4 
        connectivity, you might get a v6-only environment).
        Look at what Wercker is doing to speed up CI using containers, it shows 
a
    lot of promise as a concept.

> If travis will become essential for Gentoo development, it may
> undermine development freedom and Gentoo social contract, which
> states: "Gentoo will never depend upon a piece of software or metadata
> unless it conforms to the GNU General Public License, the GNU Lesser
> General Public License, the Creative Commons - Attribution/Share Alike
> or some other license approved by the Open Source Initiative (OSI)."
This argument has come up before, claiming that something one team is
doing isn't in line with the social contract. mgorny himself complained
about infra's repos being non-public.

Let's expand that section somewhat, from the original text:
"We will release our contributions to Gentoo as free software, metadata or
documentation, under the GNU General Public License version 2 or the Creative
Commons - Attribution / Share Alike version 2. ... However, Gentoo will never
depend upon a piece of software or metadata unless it conforms to the GNU
General Public License, the GNU Lesser General Public License, the Creative
Commons - Attribution/Share Alike or some other license approved by the Open
Source Initiative."

I'm going to use the word 'libre' below, to differentiate between a
'free-as-in-freedom' license, and the 'free-as-in-beer' offering from
commerical CI providers.

Infra's repo contents are licensed libre: most scripts I've written in the
infra repos carry a BSD license, in many cases because I wrote them for dayjob
purposes first, and later modified them for Gentoo.

We can expand this, by stating that the repos we want to test with CI must
remain libre.

It says NOTHING about the CI tools themselves. Why should we not be able to
benefit from really good closed-source CI tools that are offered for free to
the open-source community? As long as we can continue to function WITHOUT those
tools, there is no direct harm [1] done in using them. They cannot force us to
change the licenses of our repos at all. 

> Travis itself is a closed, proprietary and non-trivial-to-replace
> solution. 
If our CI testsuite contents are libre licensed (QA is running pcheck, which
is again suitably licensed), and Travis-CI or whichever CI service suddenly
because Evil(TM), there is nothing stopping us from running our testsuite
elsewhere. All that remains is hooking the testsuite into the CI service.

[1] I state direct harm here. You're going to argument that it affects the
ecosystem, by discouraging other services. Jenkins, Buildbot and others are
existing libre options in this ecosystem, but aren't keeping pace with
development.


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Reply via email to