[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:       Albert Astals Cid <aacid () kde ! org>
Date:       2016-04-21 23:03:39
Message-ID: 1528987.8TtI20lDjd () xps
[Download RAW message or body]

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@kde.org> 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@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.
> 
> 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@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?
> 
> 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
> signup.

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 
comment".

Cheers,
  Albert

> 
> > Cheers,
> > --
> > Teo Mrnjavac
> > http://teom.org | teo@kde.org
> 
> Regards,
> Ben


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