Re: Could we enable Travis-CI on our github mirrors?

[Michael Pyne]

On Fri, April 22, 2016 01:04:42 Albert Astals Cid wrote:
> El dijous, 21 d’abril de 2016, a les 15:04:57 CEST, Vishesh Handa va 
escriure:
> > On Thu, Apr 21, 2016 at 3:05 AM, Ben Cooksley  wrote:
> > >>> 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.
> > 
> > I most certainly *always* link to code on github and to the documentation.
> > 
> > > 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.
> > 
> > Except it isn't. Please point me to where it does.
> 
> I guess it depends of what you understand with "primary means of making
> contributions", if it's "pushing the code there first and then merging to
> kde repos" I think there's quite a few reasons against it in the Manifesto.

I mean, didn't we have like 3-4 huge threads about this very issue not that 
long ago? I too thought that the conclusion was that Github was OK as a mirror 
but not for use as any part of the actual development workflow (e.g. bug 
tracking, CI, pull requests, etc.).

Regards,
 - Michael Pyne

Re: Could we enable Travis-CI on our github mirrors?

[Albert Astals Cid]

El dijous, 21 d’abril de 2016, a les 15:04:57 CEST, Vishesh Handa va escriure:
> On Thu, Apr 21, 2016 at 3:05 AM, Ben Cooksley  wrote:
> >>> 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.
> 
> I most certainly *always* link to code on github and to the documentation.
> 
> > 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.
> 
> Except it isn't. Please point me to where it does.

I guess it depends of what you understand with "primary means of making 
contributions", if it's "pushing the code there first and then merging to kde 
repos" I think there's quite a few reasons against it in the Manifesto.

Cheers,
  Albert

> 
> > 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.
> 
> Please provide more info about why this would be required.
> 
> --
> Vishesh Handa

Re: Could we enable Travis-CI on our github mirrors?

[Albert Astals Cid]

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  wrote:
> > On giovedì 21 aprile 2016 13:05:31 CEST Ben Cooksley wrote:
> >> On Thu, Apr 21, 2016 at 10:05 AM, Elvis Angelaccio
> >> 
> >>  wrote:
> >> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame :
> >> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
> >> >> 
> >> >> Elvis Angelaccio  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

Re: Could we enable Travis-CI on our github mirrors?

[Vishesh Handa]

On Thu, Apr 21, 2016 at 3:05 AM, Ben Cooksley  wrote:
>>>
>>> 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.
>

I most certainly *always* link to code on github and to the documentation.

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

Except it isn't. Please point me to where it does.

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

Please provide more info about why this would be required.

--
Vishesh Handa

Re: Could we enable Travis-CI on our github mirrors?

[Ben Cooksley]

On Thu, Apr 21, 2016 at 8:01 PM, Elvis Angelaccio
 wrote:
>
>
> 2016-04-21 9:48 GMT+02:00 Ben Cooksley :
>>
>> On Thu, Apr 21, 2016 at 7:41 PM, Elvis Angelaccio
>>  wrote:
>> >
>> >
>> > 2016-04-21 3:07 GMT+02:00 Ben Cooksley :
>> >>
>> >> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio
>> >>  wrote:
>> >> >
>> >> >
>> >> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid :
>> >> >>
>> >> >> El dimecres, 20 d’abril de 2016, a les 23:00:26 CEST, Elvis
>> >> >> Angelaccio
>> >> >> va
>> >> >> escriure:
>> >> >> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid :
>> >> >> > > El dimecres, 20 d’abril de 2016, a les 18:42:31 CEST, Elvis
>> >> >> > > Angelaccio
>> >> >> > > va
>> >> >> > >
>> >> >> > > escriure:
>> >> >> > > > Hi,
>> >> >> > > > as many of you already know, KDE has a github mirror in place
>> >> >> > > > at
>> >> >> > > > [1].
>> >> >> > > > I've been playing with travis-ci [2] and I was surprised by
>> >> >> > > > how
>> >> >> > > > easy
>> >> >> > > > to
>> >> >> > >
>> >> >> > > use
>> >> >> > >
>> >> >> > > > and how well integrated with github is.
>> >> >> > > >
>> >> >> > > > I think it would be nice to have travis builds for the
>> >> >> > > > (mirrored)
>> >> >> > > > repositories that provides a .travis.yml configuration file.
>> >> >> > > > The
>> >> >> > > > builds
>> >> >> > > > would run on the travis servers, so no additional overload on
>> >> >> > > > the
>> >> >> > > > KDE
>> >> >> > > > infrastructure. There is also virtually nothing to do for KDE
>> >> >> > > > sysadmins.
>> >> >> > > > The project's maintainer is the one in charge to setup the
>> >> >> > > > travis
>> >> >> > > > configuration file (if he wants to), in order to have working
>> >> >> > > > builds.
>> >> >> > > >
>> >> >> > > > Would this be possible from a technical p.o.v.? I think the
>> >> >> > > > KDE
>> >> >> > > > github
>> >> >> > > > account would have to register on the travis website and
>> >> >> > > > "sync"
>> >> >> > > > its
>> >> >> > >
>> >> >> > > github
>> >> >> > >
>> >> >> > > > repositories - that's what I had to do with my personal github
>> >> >> > > > account.
>> >> >> > > >
>> >> >> > > > The use cases could be many. For example, on travis I can
>> >> >> > > > install
>> >> >> > >
>> >> >> > > optional
>> >> >> > >
>> >> >> > > > dependencies that are not available on our Jenkins
>> >> >> > > > installation.
>> >> >> > > > More
>> >> >> > > > details in this post [3].
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > What do you think?
>> >> >> > >
>> >> >> > > I don't see the point in having two CI systems, just help
>> >> >> > > improve
>> >> >> > > the
>> >> >> > > one
>> >> >> > > we
>> >> >> > > have.
>> >> >> > >
>> >> >> > > If you need dependencies, why did you start a new CI system
>> >> >> > > instead
>> >> >> > > of
>> >> >> > > asking
>> >> >> > > for the dependendies to be installed?
>> >> >> >
>> >> >> > Well I did ask, but those deps are not available in the Ubuntu
>> >> >> > repositories
>> >> >> > currently used by Jenkins.
>> >> >> > Maybe a solution could be to install them from source/manually,
>> >> >> > but
>> >> >> > that
>> >> >> > requires work from the sysadmins, who have already enough in their
>> >> >> > plate.
>> >> >>
>> >> >> I see. Maybe you can offer to help them?
>> >> >
>> >> >
>> >> > Not sure I have enough skills (especially now that we use docker),
>> >> > but I
>> >> > can
>> >> > ceirtainly try. Should I contact Ben?
>> >>
>> >> Docker shouldn't complicate things too much - it's essentially an
>> >> enhanced chroot.
>> >> If you're considering depending on this, have you spoken with the
>> >> Kubuntu packagers regarding getting this (hopefully non-Qt dependent)
>> >> dependency packaged?
>> >>
>> >> If it's Qt based, I do hope it isn't using QMake.
>> >
>> >
>> > They are not Qt based. In Ark we have (optional) tests that relies on
>> > packages such as unrar/rar and unarchiver. Both seems not packaged in
>> > the
>> > ubuntu version used by Jenkins.
>> > I'm fine with running these tests only locally on my system, but if
>> > there is
>> > something I can do to have them in our CI would be super-awesome.
>>
>> We run Ubuntu Wily as our base. Have you checked to see whether 16.04
>> will contain these utilities?
>> I suspect unrar/rar will be missing due to it's proprietary nature.
>
>
> This is correct. That's why we introduced a plugin for unarchiver in the
> first place.
> Yet it looks like they are both available in wily, respectively in the
> multiverse [1][2] and universe [3] repos.
>
> Would be possible to have at least [3]?
>
> [1]: http://packages.ubuntu.com/wily/unar
> [2]: http://packages.ubuntu.com/wily/rar
> [3]: http://packages.ubuntu.com/wily/unar

Aha. I've now actioned that, so they'll be available next time the CI
images are rebuilt.

Thanks,
Ben

>
>
>>
>>
>> Cheers,
>> Ben
>>
>> >

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-21 9:48 GMT+02:00 Ben Cooksley :

> On Thu, Apr 21, 2016 at 7:41 PM, Elvis Angelaccio
>  wrote:
> >
> >
> > 2016-04-21 3:07 GMT+02:00 Ben Cooksley :
> >>
> >> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio
> >>  wrote:
> >> >
> >> >
> >> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid :
> >> >>
> >> >> El dimecres, 20 d’abril de 2016, a les 23:00:26 CEST, Elvis
> Angelaccio
> >> >> va
> >> >> escriure:
> >> >> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid :
> >> >> > > El dimecres, 20 d’abril de 2016, a les 18:42:31 CEST, Elvis
> >> >> > > Angelaccio
> >> >> > > va
> >> >> > >
> >> >> > > escriure:
> >> >> > > > Hi,
> >> >> > > > as many of you already know, KDE has a github mirror in place
> at
> >> >> > > > [1].
> >> >> > > > I've been playing with travis-ci [2] and I was surprised by how
> >> >> > > > easy
> >> >> > > > to
> >> >> > >
> >> >> > > use
> >> >> > >
> >> >> > > > and how well integrated with github is.
> >> >> > > >
> >> >> > > > I think it would be nice to have travis builds for the
> (mirrored)
> >> >> > > > repositories that provides a .travis.yml configuration file.
> The
> >> >> > > > builds
> >> >> > > > would run on the travis servers, so no additional overload on
> the
> >> >> > > > KDE
> >> >> > > > infrastructure. There is also virtually nothing to do for KDE
> >> >> > > > sysadmins.
> >> >> > > > The project's maintainer is the one in charge to setup the
> travis
> >> >> > > > configuration file (if he wants to), in order to have working
> >> >> > > > builds.
> >> >> > > >
> >> >> > > > Would this be possible from a technical p.o.v.? I think the KDE
> >> >> > > > github
> >> >> > > > account would have to register on the travis website and "sync"
> >> >> > > > its
> >> >> > >
> >> >> > > github
> >> >> > >
> >> >> > > > repositories - that's what I had to do with my personal github
> >> >> > > > account.
> >> >> > > >
> >> >> > > > The use cases could be many. For example, on travis I can
> install
> >> >> > >
> >> >> > > optional
> >> >> > >
> >> >> > > > dependencies that are not available on our Jenkins
> installation.
> >> >> > > > More
> >> >> > > > details in this post [3].
> >> >> > > >
> >> >> > > >
> >> >> > > > What do you think?
> >> >> > >
> >> >> > > I don't see the point in having two CI systems, just help improve
> >> >> > > the
> >> >> > > one
> >> >> > > we
> >> >> > > have.
> >> >> > >
> >> >> > > If you need dependencies, why did you start a new CI system
> instead
> >> >> > > of
> >> >> > > asking
> >> >> > > for the dependendies to be installed?
> >> >> >
> >> >> > Well I did ask, but those deps are not available in the Ubuntu
> >> >> > repositories
> >> >> > currently used by Jenkins.
> >> >> > Maybe a solution could be to install them from source/manually, but
> >> >> > that
> >> >> > requires work from the sysadmins, who have already enough in their
> >> >> > plate.
> >> >>
> >> >> I see. Maybe you can offer to help them?
> >> >
> >> >
> >> > Not sure I have enough skills (especially now that we use docker),
> but I
> >> > can
> >> > ceirtainly try. Should I contact Ben?
> >>
> >> Docker shouldn't complicate things too much - it's essentially an
> >> enhanced chroot.
> >> If you're considering depending on this, have you spoken with the
> >> Kubuntu packagers regarding getting this (hopefully non-Qt dependent)
> >> dependency packaged?
> >>
> >> If it's Qt based, I do hope it isn't using QMake.
> >
> >
> > They are not Qt based. In Ark we have (optional) tests that relies on
> > packages such as unrar/rar and unarchiver. Both seems not packaged in the
> > ubuntu version used by Jenkins.
> > I'm fine with running these tests only locally on my system, but if
> there is
> > something I can do to have them in our CI would be super-awesome.
>
> We run Ubuntu Wily as our base. Have you checked to see whether 16.04
> will contain these utilities?
> I suspect unrar/rar will be missing due to it's proprietary nature.
>

This is correct. That's why we introduced a plugin for unarchiver in the
first place.
Yet it looks like they are both available in wily, respectively in the
multiverse [1][2] and universe [3] repos.

Would be possible to have at least [3]?

[1]: http://packages.ubuntu.com/wily/unar
[2]: http://packages.ubuntu.com/wily/rar
[3]: http://packages.ubuntu.com/wily/unar



>
> Cheers,
> Ben
>
> >
> >>
> >>
> >> Regards,
> >> Ben
> >>
> >> >
> >> >>
> >> >>
> >> >> > I did not start a new CI, I was basically playing with travis for
> >> >> > fun.
> >> >> > But
> >> >> > then it turned out that it could solve an issue I have. The travis
> >> >> > infrastrucure is already there, why not use it if one or more
> >> >> > projects
> >> >> > could benefit? Seems a win-win to me.
> >> >>
> >> >> As a release team member i won't look at the github CI
> >> >>
> >> >> I will look at our official one, but you will look at the 

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-21 9:32 GMT+02:00 Harald Sitter :

> On Wed, Apr 20, 2016 at 6:42 PM, Elvis Angelaccio
>  wrote:
> > Hi,
> > as many of you already know, KDE has a github mirror in place at [1].
> > I've been playing with travis-ci [2] and I was surprised by how easy to
> use
> > and how well integrated with github is.
> >
> > I think it would be nice to have travis builds for the (mirrored)
> > repositories that provides a .travis.yml configuration file. The builds
> > would run on the travis servers, so no additional overload on the KDE
> > infrastructure. There is also virtually nothing to do for KDE sysadmins.
> The
> > project's maintainer is the one in charge to setup the travis
> configuration
> > file (if he wants to), in order to have working builds.
> >
> > Would this be possible from a technical p.o.v.? I think the KDE github
> > account would have to register on the travis website and "sync" its
> github
> > repositories - that's what I had to do with my personal github account.
> >
> > The use cases could be many. For example, on travis I can install
> optional
> > dependencies that are not available on our Jenkins installation. More
> > details in this post [3].
> >
> >
> > What do you think?
>
> Just have the main devs do a double push to an unoffical mirror...
>
> $ cat .git/config | grep pushurl
>pushurl = kde:releaseme
>pushurl = g...@github.com:apachelogger/releaseme.git
>
> FWIW, I find it sad that as a community we apparently don't have
> enough integrity so we can enable support for a third party CI tool
> without having it undermine our tool, which just BTW doesn't even play
> in the same league as far as large scale stack integration goes.
> What sort of culture is that anyway where we stand in the way of devs
> trying to make things more awesome because of "oh but this might maybe
> will happen". I am so incredibly disappointed.
>

Hi Harald,
the double push looks like a good trade-off to me! Thanks for sharing


>
> HS
>

Re: Could we enable Travis-CI on our github mirrors?

[Ben Cooksley]

On Thu, Apr 21, 2016 at 7:41 PM, Elvis Angelaccio
 wrote:
>
>
> 2016-04-21 3:07 GMT+02:00 Ben Cooksley :
>>
>> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio
>>  wrote:
>> >
>> >
>> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid :
>> >>
>> >> El dimecres, 20 d’abril de 2016, a les 23:00:26 CEST, Elvis Angelaccio
>> >> va
>> >> escriure:
>> >> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid :
>> >> > > El dimecres, 20 d’abril de 2016, a les 18:42:31 CEST, Elvis
>> >> > > Angelaccio
>> >> > > va
>> >> > >
>> >> > > escriure:
>> >> > > > Hi,
>> >> > > > as many of you already know, KDE has a github mirror in place at
>> >> > > > [1].
>> >> > > > I've been playing with travis-ci [2] and I was surprised by how
>> >> > > > easy
>> >> > > > to
>> >> > >
>> >> > > use
>> >> > >
>> >> > > > and how well integrated with github is.
>> >> > > >
>> >> > > > I think it would be nice to have travis builds for the (mirrored)
>> >> > > > repositories that provides a .travis.yml configuration file. The
>> >> > > > builds
>> >> > > > would run on the travis servers, so no additional overload on the
>> >> > > > KDE
>> >> > > > infrastructure. There is also virtually nothing to do for KDE
>> >> > > > sysadmins.
>> >> > > > The project's maintainer is the one in charge to setup the travis
>> >> > > > configuration file (if he wants to), in order to have working
>> >> > > > builds.
>> >> > > >
>> >> > > > Would this be possible from a technical p.o.v.? I think the KDE
>> >> > > > github
>> >> > > > account would have to register on the travis website and "sync"
>> >> > > > its
>> >> > >
>> >> > > github
>> >> > >
>> >> > > > repositories - that's what I had to do with my personal github
>> >> > > > account.
>> >> > > >
>> >> > > > The use cases could be many. For example, on travis I can install
>> >> > >
>> >> > > optional
>> >> > >
>> >> > > > dependencies that are not available on our Jenkins installation.
>> >> > > > More
>> >> > > > details in this post [3].
>> >> > > >
>> >> > > >
>> >> > > > What do you think?
>> >> > >
>> >> > > I don't see the point in having two CI systems, just help improve
>> >> > > the
>> >> > > one
>> >> > > we
>> >> > > have.
>> >> > >
>> >> > > If you need dependencies, why did you start a new CI system instead
>> >> > > of
>> >> > > asking
>> >> > > for the dependendies to be installed?
>> >> >
>> >> > Well I did ask, but those deps are not available in the Ubuntu
>> >> > repositories
>> >> > currently used by Jenkins.
>> >> > Maybe a solution could be to install them from source/manually, but
>> >> > that
>> >> > requires work from the sysadmins, who have already enough in their
>> >> > plate.
>> >>
>> >> I see. Maybe you can offer to help them?
>> >
>> >
>> > Not sure I have enough skills (especially now that we use docker), but I
>> > can
>> > ceirtainly try. Should I contact Ben?
>>
>> Docker shouldn't complicate things too much - it's essentially an
>> enhanced chroot.
>> If you're considering depending on this, have you spoken with the
>> Kubuntu packagers regarding getting this (hopefully non-Qt dependent)
>> dependency packaged?
>>
>> If it's Qt based, I do hope it isn't using QMake.
>
>
> They are not Qt based. In Ark we have (optional) tests that relies on
> packages such as unrar/rar and unarchiver. Both seems not packaged in the
> ubuntu version used by Jenkins.
> I'm fine with running these tests only locally on my system, but if there is
> something I can do to have them in our CI would be super-awesome.

We run Ubuntu Wily as our base. Have you checked to see whether 16.04
will contain these utilities?
I suspect unrar/rar will be missing due to it's proprietary nature.

Cheers,
Ben

>
>>
>>
>> Regards,
>> Ben
>>
>> >
>> >>
>> >>
>> >> > I did not start a new CI, I was basically playing with travis for
>> >> > fun.
>> >> > But
>> >> > then it turned out that it could solve an issue I have. The travis
>> >> > infrastrucure is already there, why not use it if one or more
>> >> > projects
>> >> > could benefit? Seems a win-win to me.
>> >>
>> >> As a release team member i won't look at the github CI
>> >>
>> >> I will look at our official one, but you will look at the github one
>> >> since
>> >> for
>> >> you "it's better"
>> >
>> >
>> > I never said it's better. I think it would be a nice addition, doesn't
>> > mean
>> > that I would stop looking at our main CI
>> >
>> >>
>> >>
>> >> I can see this creating problems, like for example build.kde.org
>> >> passing
>> >> and
>> >> githubCI not passing and you getting mad at me because we released
>> >> something
>> >> that doesn't work.
>> >
>> >
>> > This is a fair point, but see also my previous reply to Luca (the "who
>> > cares" part).
>> > I can promise you that I won't get mad at you, fwiw :)
>> >
>> >>
>> >>
>> >> Cheers,
>> >>   Albert
>> >>
>> >> >
>> >> > > Cheers,
>> >> > >
>> >> > >   Albert
>> >> >
>> >> > 

Telegram usage by KDE people (was Re: Could we enable Travis-CI on our github mirrors?)

[Luca Beltrame]

Il giorno Thu, 21 Apr 2016 09:31:23 +0200
Elvis Angelaccio  ha scritto:

> To be fair, similar concerns should then be raised lalso against our
> usage of Telegram (which seems to me less open than Travis, btw).

FWIW, I think it's a really, really bad idea to use Telegram for the
same reason. Closed source server component, and questionable crypto at
best (not said by me, but by people far smarter than me), which is a
huge minus these days. Nothing prevents usage of Telegram by KDE people,
as long, however, that this doesn't become a "de facto" usage by KDE.


pgpBD4htyF4en.pgp
Description: Firma digitale OpenPGP

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-21 3:07 GMT+02:00 Ben Cooksley :

> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio
>  wrote:
> >
> >
> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid :
> >>
> >> El dimecres, 20 d’abril de 2016, a les 23:00:26 CEST, Elvis Angelaccio
> va
> >> escriure:
> >> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid :
> >> > > El dimecres, 20 d’abril de 2016, a les 18:42:31 CEST, Elvis
> Angelaccio
> >> > > va
> >> > >
> >> > > escriure:
> >> > > > Hi,
> >> > > > as many of you already know, KDE has a github mirror in place at
> >> > > > [1].
> >> > > > I've been playing with travis-ci [2] and I was surprised by how
> easy
> >> > > > to
> >> > >
> >> > > use
> >> > >
> >> > > > and how well integrated with github is.
> >> > > >
> >> > > > I think it would be nice to have travis builds for the (mirrored)
> >> > > > repositories that provides a .travis.yml configuration file. The
> >> > > > builds
> >> > > > would run on the travis servers, so no additional overload on the
> >> > > > KDE
> >> > > > infrastructure. There is also virtually nothing to do for KDE
> >> > > > sysadmins.
> >> > > > The project's maintainer is the one in charge to setup the travis
> >> > > > configuration file (if he wants to), in order to have working
> >> > > > builds.
> >> > > >
> >> > > > Would this be possible from a technical p.o.v.? I think the KDE
> >> > > > github
> >> > > > account would have to register on the travis website and "sync"
> its
> >> > >
> >> > > github
> >> > >
> >> > > > repositories - that's what I had to do with my personal github
> >> > > > account.
> >> > > >
> >> > > > The use cases could be many. For example, on travis I can install
> >> > >
> >> > > optional
> >> > >
> >> > > > dependencies that are not available on our Jenkins installation.
> >> > > > More
> >> > > > details in this post [3].
> >> > > >
> >> > > >
> >> > > > What do you think?
> >> > >
> >> > > I don't see the point in having two CI systems, just help improve
> the
> >> > > one
> >> > > we
> >> > > have.
> >> > >
> >> > > If you need dependencies, why did you start a new CI system instead
> of
> >> > > asking
> >> > > for the dependendies to be installed?
> >> >
> >> > Well I did ask, but those deps are not available in the Ubuntu
> >> > repositories
> >> > currently used by Jenkins.
> >> > Maybe a solution could be to install them from source/manually, but
> that
> >> > requires work from the sysadmins, who have already enough in their
> >> > plate.
> >>
> >> I see. Maybe you can offer to help them?
> >
> >
> > Not sure I have enough skills (especially now that we use docker), but I
> can
> > ceirtainly try. Should I contact Ben?
>
> Docker shouldn't complicate things too much - it's essentially an
> enhanced chroot.
> If you're considering depending on this, have you spoken with the
> Kubuntu packagers regarding getting this (hopefully non-Qt dependent)
> dependency packaged?
>
> If it's Qt based, I do hope it isn't using QMake.
>

They are not Qt based. In Ark we have (optional) tests that relies on
packages such as unrar/rar and unarchiver. Both seems not packaged in the
ubuntu version used by Jenkins.
I'm fine with running these tests only locally on my system, but if there
is something I can do to have them in our CI would be super-awesome.


>
> Regards,
> Ben
>
> >
> >>
> >>
> >> > I did not start a new CI, I was basically playing with travis for fun.
> >> > But
> >> > then it turned out that it could solve an issue I have. The travis
> >> > infrastrucure is already there, why not use it if one or more projects
> >> > could benefit? Seems a win-win to me.
> >>
> >> As a release team member i won't look at the github CI
> >>
> >> I will look at our official one, but you will look at the github one
> since
> >> for
> >> you "it's better"
> >
> >
> > I never said it's better. I think it would be a nice addition, doesn't
> mean
> > that I would stop looking at our main CI
> >
> >>
> >>
> >> I can see this creating problems, like for example build.kde.org
> passing
> >> and
> >> githubCI not passing and you getting mad at me because we released
> >> something
> >> that doesn't work.
> >
> >
> > This is a fair point, but see also my previous reply to Luca (the "who
> > cares" part).
> > I can promise you that I won't get mad at you, fwiw :)
> >
> >>
> >>
> >> Cheers,
> >>   Albert
> >>
> >> >
> >> > > Cheers,
> >> > >
> >> > >   Albert
> >> >
> >> > Cheers,
> >> > Elvis
> >> >
> >> > > > Regards,
> >> > > > Elvis
> >> > > >
> >> > > >
> >> > > > [1]: https://github.com/KDE
> >> > > > [2]: https://travis-ci.org/
> >> > >
> >> > > > [3]:
> >> > >
> >> > >
> http://www.aelog.org/travis-ci-builds-of-kde-projects-on-archlinux-chroot/
> >>
> >>
> >
>

Re: Could we enable Travis-CI on our github mirrors?

[Harald Sitter]

On Wed, Apr 20, 2016 at 6:42 PM, Elvis Angelaccio
 wrote:
> Hi,
> as many of you already know, KDE has a github mirror in place at [1].
> I've been playing with travis-ci [2] and I was surprised by how easy to use
> and how well integrated with github is.
>
> I think it would be nice to have travis builds for the (mirrored)
> repositories that provides a .travis.yml configuration file. The builds
> would run on the travis servers, so no additional overload on the KDE
> infrastructure. There is also virtually nothing to do for KDE sysadmins. The
> project's maintainer is the one in charge to setup the travis configuration
> file (if he wants to), in order to have working builds.
>
> Would this be possible from a technical p.o.v.? I think the KDE github
> account would have to register on the travis website and "sync" its github
> repositories - that's what I had to do with my personal github account.
>
> The use cases could be many. For example, on travis I can install optional
> dependencies that are not available on our Jenkins installation. More
> details in this post [3].
>
>
> What do you think?

Just have the main devs do a double push to an unoffical mirror...

$ cat .git/config | grep pushurl
   pushurl = kde:releaseme
   pushurl = g...@github.com:apachelogger/releaseme.git

FWIW, I find it sad that as a community we apparently don't have
enough integrity so we can enable support for a third party CI tool
without having it undermine our tool, which just BTW doesn't even play
in the same league as far as large scale stack integration goes.
What sort of culture is that anyway where we stand in the way of devs
trying to make things more awesome because of "oh but this might maybe
will happen". I am so incredibly disappointed.

HS

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-21 8:30 GMT+02:00 Frederik Schwarzer :

> Am 21.04.2016 07:56 schrieb Teo Mrnjavac:
>
> Hi,
>
> Can we call things as they are please? The name is "Travis CI", not
>> "githubCI". Travis CI is open source, a separate product and service that
>> happens to talk to GitHub.
>>
>
> I think Albert's concern is (and I agree) that the meaning of a potential
> Travis-hosted CI is shifting over time from "addition" to "main one".
> People tend to do this. Oh, this one feature here, oh, the easier login
> there ...
>
> In general I think 3rd party services should be avoided to get an official
> status in KDE. Sourceforge suddenly started adding adware to all downloads.
> Github can do the same. Tomorrow, nezt week, next year. They might announce
> this first or they don't. The same way TravixCI could say, they now want
> money or put ads all over the place. We have no control over this at all.
> So it is better to invest some time and money to maintain our own
> infrastructure. It makes us independent from some management decision made
> by some company. Also, for an infrastructure inside KDE, we need people to
> work on it. If now people start to use 3rd party sevices, less people are
> looking at our infrastructure and it gets less attention. That's at least
> why I would vote against that kind of "additions" made official. If some
> developer wants to use something somewhere, I guess there is nothing to
> hold him back but KDE shoud remain as self-contained as possible. Wth all
> the little problems coming with this.
>

To be fair, similar concerns should then be raised lalso against our usage
of Telegram (which seems to me less open than Travis, btw).


>
> Regards,
> Frederik
>

Cheers,
Elvis

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-21 3:05 GMT+02:00 Ben Cooksley :

> On Thu, Apr 21, 2016 at 10:05 AM, Elvis Angelaccio
>  wrote:
> >
> >
> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame :
> >>
> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
> >> Elvis Angelaccio  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.
>
> 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.
>

Sorry it looks I was wrong. I was confused by projects like Calamares and
Wikitolearn, but after double-checking with Luigi it seems the former is
not an official KDE project and the latter is still in the incubating phase
(?). Sorry about the noise :(


>
> >
> >>
> >>
> >> --
> >> Luca Beltrame - KDE Forums team
> >> GPG key ID: A29D259B
> >
> >
>
> Regards,
> Ben
>

Re: Could we enable Travis-CI on our github mirrors?

[Ben Cooksley]

On Thu, Apr 21, 2016 at 6:16 PM, Teo Mrnjavac  wrote:
> On giovedì 21 aprile 2016 13:05:31 CEST Ben Cooksley wrote:
>> On Thu, Apr 21, 2016 at 10:05 AM, Elvis Angelaccio
>>
>>  wrote:
>> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame :
>> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
>> >>
>> >> Elvis Angelaccio  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.

>
> Cheers,
> --
> Teo Mrnjavac
> http://teom.org | t...@kde.org

Regards,
Ben

Re: Could we enable Travis-CI on our github mirrors?

[Frederik Schwarzer]

Am 21.04.2016 07:56 schrieb Teo Mrnjavac:

Hi,


Can we call things as they are please? The name is "Travis CI", not
"githubCI". Travis CI is open source, a separate product and service 
that

happens to talk to GitHub.


I think Albert's concern is (and I agree) that the meaning of a 
potential Travis-hosted CI is shifting over time from "addition" to 
"main one". People tend to do this. Oh, this one feature here, oh, the 
easier login there ...


In general I think 3rd party services should be avoided to get an 
official status in KDE. Sourceforge suddenly started adding adware to 
all downloads. Github can do the same. Tomorrow, nezt week, next year. 
They might announce this first or they don't. The same way TravixCI 
could say, they now want money or put ads all over the place. We have no 
control over this at all. So it is better to invest some time and money 
to maintain our own infrastructure. It makes us independent from some 
management decision made by some company. Also, for an infrastructure 
inside KDE, we need people to work on it. If now people start to use 3rd 
party sevices, less people are looking at our infrastructure and it gets 
less attention. That's at least why I would vote against that kind of 
"additions" made official. If some developer wants to use something 
somewhere, I guess there is nothing to hold him back but KDE shoud 
remain as self-contained as possible. Wth all the little problems coming 
with this.


Regards,
Frederik

Re: Could we enable Travis-CI on our github mirrors?

[Teo Mrnjavac]

On giovedì 21 aprile 2016 13:05:31 CEST Ben Cooksley wrote:
> On Thu, Apr 21, 2016 at 10:05 AM, Elvis Angelaccio
> 
>  wrote:
> > 2016-04-20 23:09 GMT+02:00 Luca Beltrame :
> >> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
> >> 
> >> Elvis Angelaccio  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-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?

Cheers,
-- 
Teo Mrnjavac
http://teom.org | t...@kde.org

Re: Could we enable Travis-CI on our github mirrors?

[Ben Cooksley]

On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio
 wrote:
>
>
> 2016-04-20 23:20 GMT+02:00 Albert Astals Cid :
>>
>> El dimecres, 20 d’abril de 2016, a les 23:00:26 CEST, Elvis Angelaccio va
>> escriure:
>> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid :
>> > > El dimecres, 20 d’abril de 2016, a les 18:42:31 CEST, Elvis Angelaccio
>> > > va
>> > >
>> > > escriure:
>> > > > Hi,
>> > > > as many of you already know, KDE has a github mirror in place at
>> > > > [1].
>> > > > I've been playing with travis-ci [2] and I was surprised by how easy
>> > > > to
>> > >
>> > > use
>> > >
>> > > > and how well integrated with github is.
>> > > >
>> > > > I think it would be nice to have travis builds for the (mirrored)
>> > > > repositories that provides a .travis.yml configuration file. The
>> > > > builds
>> > > > would run on the travis servers, so no additional overload on the
>> > > > KDE
>> > > > infrastructure. There is also virtually nothing to do for KDE
>> > > > sysadmins.
>> > > > The project's maintainer is the one in charge to setup the travis
>> > > > configuration file (if he wants to), in order to have working
>> > > > builds.
>> > > >
>> > > > Would this be possible from a technical p.o.v.? I think the KDE
>> > > > github
>> > > > account would have to register on the travis website and "sync" its
>> > >
>> > > github
>> > >
>> > > > repositories - that's what I had to do with my personal github
>> > > > account.
>> > > >
>> > > > The use cases could be many. For example, on travis I can install
>> > >
>> > > optional
>> > >
>> > > > dependencies that are not available on our Jenkins installation.
>> > > > More
>> > > > details in this post [3].
>> > > >
>> > > >
>> > > > What do you think?
>> > >
>> > > I don't see the point in having two CI systems, just help improve the
>> > > one
>> > > we
>> > > have.
>> > >
>> > > If you need dependencies, why did you start a new CI system instead of
>> > > asking
>> > > for the dependendies to be installed?
>> >
>> > Well I did ask, but those deps are not available in the Ubuntu
>> > repositories
>> > currently used by Jenkins.
>> > Maybe a solution could be to install them from source/manually, but that
>> > requires work from the sysadmins, who have already enough in their
>> > plate.
>>
>> I see. Maybe you can offer to help them?
>
>
> Not sure I have enough skills (especially now that we use docker), but I can
> ceirtainly try. Should I contact Ben?

Docker shouldn't complicate things too much - it's essentially an
enhanced chroot.
If you're considering depending on this, have you spoken with the
Kubuntu packagers regarding getting this (hopefully non-Qt dependent)
dependency packaged?

If it's Qt based, I do hope it isn't using QMake.

Regards,
Ben

>
>>
>>
>> > I did not start a new CI, I was basically playing with travis for fun.
>> > But
>> > then it turned out that it could solve an issue I have. The travis
>> > infrastrucure is already there, why not use it if one or more projects
>> > could benefit? Seems a win-win to me.
>>
>> As a release team member i won't look at the github CI
>>
>> I will look at our official one, but you will look at the github one since
>> for
>> you "it's better"
>
>
> I never said it's better. I think it would be a nice addition, doesn't mean
> that I would stop looking at our main CI
>
>>
>>
>> I can see this creating problems, like for example build.kde.org passing
>> and
>> githubCI not passing and you getting mad at me because we released
>> something
>> that doesn't work.
>
>
> This is a fair point, but see also my previous reply to Luca (the "who
> cares" part).
> I can promise you that I won't get mad at you, fwiw :)
>
>>
>>
>> Cheers,
>>   Albert
>>
>> >
>> > > Cheers,
>> > >
>> > >   Albert
>> >
>> > Cheers,
>> > Elvis
>> >
>> > > > Regards,
>> > > > Elvis
>> > > >
>> > > >
>> > > > [1]: https://github.com/KDE
>> > > > [2]: https://travis-ci.org/
>> > >
>> > > > [3]:
>> > >
>> > > http://www.aelog.org/travis-ci-builds-of-kde-projects-on-archlinux-chroot/
>>
>>
>

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-20 23:20 GMT+02:00 Albert Astals Cid :

> El dimecres, 20 d’abril de 2016, a les 23:00:26 CEST, Elvis Angelaccio va
> escriure:
> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid :
> > > El dimecres, 20 d’abril de 2016, a les 18:42:31 CEST, Elvis Angelaccio
> va
> > >
> > > escriure:
> > > > Hi,
> > > > as many of you already know, KDE has a github mirror in place at [1].
> > > > I've been playing with travis-ci [2] and I was surprised by how easy
> to
> > >
> > > use
> > >
> > > > and how well integrated with github is.
> > > >
> > > > I think it would be nice to have travis builds for the (mirrored)
> > > > repositories that provides a .travis.yml configuration file. The
> builds
> > > > would run on the travis servers, so no additional overload on the KDE
> > > > infrastructure. There is also virtually nothing to do for KDE
> sysadmins.
> > > > The project's maintainer is the one in charge to setup the travis
> > > > configuration file (if he wants to), in order to have working builds.
> > > >
> > > > Would this be possible from a technical p.o.v.? I think the KDE
> github
> > > > account would have to register on the travis website and "sync" its
> > >
> > > github
> > >
> > > > repositories - that's what I had to do with my personal github
> account.
> > > >
> > > > The use cases could be many. For example, on travis I can install
> > >
> > > optional
> > >
> > > > dependencies that are not available on our Jenkins installation. More
> > > > details in this post [3].
> > > >
> > > >
> > > > What do you think?
> > >
> > > I don't see the point in having two CI systems, just help improve the
> one
> > > we
> > > have.
> > >
> > > If you need dependencies, why did you start a new CI system instead of
> > > asking
> > > for the dependendies to be installed?
> >
> > Well I did ask, but those deps are not available in the Ubuntu
> repositories
> > currently used by Jenkins.
> > Maybe a solution could be to install them from source/manually, but that
> > requires work from the sysadmins, who have already enough in their plate.
>
> I see. Maybe you can offer to help them?
>

Not sure I have enough skills (especially now that we use docker), but I
can ceirtainly try. Should I contact Ben?


>
> > I did not start a new CI, I was basically playing with travis for fun.
> But
> > then it turned out that it could solve an issue I have. The travis
> > infrastrucure is already there, why not use it if one or more projects
> > could benefit? Seems a win-win to me.
>
> As a release team member i won't look at the github CI
>
> I will look at our official one, but you will look at the github one since
> for
> you "it's better"
>

I never said it's better. I think it would be a nice addition, doesn't mean
that I would stop looking at our main CI


>
> I can see this creating problems, like for example build.kde.org passing
> and
> githubCI not passing and you getting mad at me because we released
> something
> that doesn't work.
>

This is a fair point, but see also my previous reply to Luca (the "who
cares" part).
I can promise you that I won't get mad at you, fwiw :)


>
> Cheers,
>   Albert
>
> >
> > > Cheers,
> > >
> > >   Albert
> >
> > Cheers,
> > Elvis
> >
> > > > Regards,
> > > > Elvis
> > > >
> > > >
> > > > [1]: https://github.com/KDE
> > > > [2]: https://travis-ci.org/
> > >
> > > > [3]:
> > >
> http://www.aelog.org/travis-ci-builds-of-kde-projects-on-archlinux-chroot/
>
>
>

Re: Could we enable Travis-CI on our github mirrors?

[Elvis Angelaccio]

2016-04-20 23:09 GMT+02:00 Luca Beltrame :

> Il giorno Wed, 20 Apr 2016 18:42:31 +0200
> Elvis Angelaccio  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.


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


>
> --
> Luca Beltrame - KDE Forums team
> GPG key ID: A29D259B
>

Re: Could we enable Travis-CI on our github mirrors?

[Luca Beltrame]

Il giorno Wed, 20 Apr 2016 18:42:31 +0200
Elvis Angelaccio  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.

Also, another -1 from me is because I don't think we should use GitHub
more than a mere mirror.

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B


pgpIZboi3_PIq.pgp
Description: Firma digitale OpenPGP