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 <t...@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.angelac...@kdemail.net> wrote: > >> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame <lbeltr...@kde.org>: > >> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200 > >> >> > >> >> Elvis Angelaccio <elvis.angelac...@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-commun...@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 | t...@kde.org > > Regards, > Ben