[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Could we enable Travis-CI on our github mirrors?
From:       Teo Mrnjavac <teo () kde ! org>
Date:       2016-04-21 6:16:40
Message-ID: 4596862.d5Eg2ke01T () serenia
[Download RAW message or body]

On giovedì 21 aprile 2016 13:05:31 CEST Ben Cooksley wrote:
> On Thu, Apr 21, 2016 at 10:05 AM, Elvis Angelaccio
> 
> <elvis.angelaccio@kdemail.net> wrote:
> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame <lbeltrame@kde.org>:
> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
> >> 
> >> Elvis Angelaccio <elvis.angelaccio@kdemail.net> ha scritto:
> >> > I think it would be nice to have travis builds for the (mirrored)
> >> > repositories that provides a .travis.yml configuration file. The
> >> 
> >> -1. Aside the arguments moved by Albert, I add that the solution is
> >> finding ways to help whoever is working on CI rather than offloading to
> >> another service we do not control.
> > 
> > I don't see it as an offloading. More like a nice bonus to have. If it
> > works, good. If not (because it breaks and we don't have control on it),
> > who cares.
> > In a way, one could argue this is similar to the telegram case. We don't
> > have control over telegram either, but it works for some people and it's
> > not replacing the main communication channels. So it's just a nice
> > addition to have.
> 
> I see it as a point of complication, which will add confusion to our
> existing infrastructure.
> It will also increase workload on Sysadmin, as projects will have to
> request it to be enabled, and undoubtedly people will want things to
> be fixed by us or otherwise supported by us once they begin using it.

It can be enabled for all repositories, and only those that have a .travis.yml 
file would be picked up by Travis CI. So maximum control for project 
maintainers to choose whether they want to use it and how. Why would Sysadmin 
have to support it? Elvis is just asking Sysadmin to allow him to set it up on 
his own for his repository through the GitHub mirror.

> 
> We therefore will not be enabling any support for Travis or other
> services which integrate with Github.
> 
> All CI integration will be done using our existing CI system, build.kde.org.
> Issues with it's functionality should be rectified there.
> 
> >> Also, another -1 from me is because I don't think we should use GitHub
> >> more than a mere mirror.
> > 
> > It would still remain a mere mirror imho, i.e. strictly read-only. Btw do
> > we have some written rule about our github presence somewhere? It seems
> > to me that some KDE project uses github as their main development
> > platform.
> Urls to those projects which "appear" to be using Github as their
> primary development platform would be appreciated.
> 
> Use of Github for anything other than mirror purposes, especially if
> it is being pushed as the primary means of making contributions is
> strictly prohibited under the Manifesto. The projects included above
> can expect to hear from Sysadmin and will be requested to provide an
> explanation of their activities there to both us and
> kde-community@kde.org.
> 

So snitching on your mates (on dubious "appear to be using GitHub as primary 
platform" charges) is encouraged, but woe to you if you set up a secondary, 
hosted, automated, unofficial open source CI service that happens to talk to 
GitHub?

Is this bizarro world?

Cheers,
-- 
Teo Mrnjavac
http://teom.org | teo@kde.org
[prev in list] [next in list] [prev in thread] [next in thread]