Re: Could we enable Travis-CI on our github mirrors?
- Date: Fri, 22 Apr 2016 01:03:39 +0200
- From: Albert Astals Cid <aacid@xxxxxxx>
- Subject: Re: Could we enable Travis-CI on our github mirrors?
El dijous, 21 d’abril de 2016, a les 18:35:14 CEST, Ben Cooksley va escriure:
> On Thu, Apr 21, 2016 at 6:16 PM, Teo Mrnjavac <teo@xxxxxxx> wrote:
> > 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@xxxxxxxxxxx> wrote:
> >> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame <lbeltrame@xxxxxxx>:
> >> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
> >> >>
> >> >> Elvis Angelaccio <elvis.angelaccio@xxxxxxxxxxx> 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.
> I'm speaking from experience here.
> Things have a nasty habit of moving from "opt in by one project" to
> being "sysadmin supported".
> We also have an existing CI system, so why you'd want to duplicate
> effort I have no idea.
> >> 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@xxxxxxx.
> > 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?
> I'm more referring to code review there. That breaks our KDE
> Developers participate equally model, as for various reasons some of
> our members don't want to work with Github, and it requires additional
I thought pre-commit code review had been settled with "if it's ok to do it by
email, on irc or on in-person, it's ok to do it in github".
After all pre-commit code review as we do it nowadays is not so that everyone
has the change to comment before the commit happens, otherwise we'd have a
clause like "you can not commit in two weeks so that everyone has time to
> > Cheers,
> > --
> > Teo Mrnjavac
> > http://teom.org | teo@xxxxxxx