Quantcast

GIMP testing cooperation

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GIMP testing cooperation

Vladimír Beneš
Hi all,
we (at Red Hat) are very interested in GIMP as we do use it and we also
do test it (but not the latests releases). We would like to start or
participate in an automated testing efforts of upstream releases or
possibly master branch. I am not sure if you have anything ready for
automated testing of latest code but I wasn't able to find anything. We
do have some basic test set in-house but coverage is really far away
from ideal and as we have some resources to invest it would be nice to
properly cooperate in upstream directly.
We would be quite interested to set up a CI system if there is none or
possibly use GNOME continuous if applicable. Definitely open to ideas
here.
As for coding style we are quite happy users of python Behave [1]
framework in not only GNOME projects using Dogtail [2] over a11y layer
or some kind of expect [3] if tests are cli based. For the code
readability and easiness to code we do use python to connect all these
together.
A good example of such code is in gnome-calculator [4] in feature files
or in gnome-boxes [5].

If you have any ideas where our cooperation should start or if you have
something ready and just not visible to us please point me to the right
direction.

Looking forward to hearing from you,
Vladimir

[1] http://pythonhosted.org/behave/tutorial.html
[2] https://fedorahosted.org/dogtail/
[3] https://pexpect.readthedocs.io/en/stable/
[4] https://git.gnome.org/browse/gnome-calculator/tree/tests
[5] https://git.gnome.org/browse/gnome-boxes/tree/tests

_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Jehan Pagès
Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:

> Hi all,
> we (at Red Hat) are very interested in GIMP as we do use it and we also
> do test it (but not the latests releases). We would like to start or
> participate in an automated testing efforts of upstream releases or
> possibly master branch. I am not sure if you have anything ready for
> automated testing of latest code but I wasn't able to find anything. We
> do have some basic test set in-house but coverage is really far away
> from ideal and as we have some resources to invest it would be nice to
> properly cooperate in upstream directly.
> We would be quite interested to set up a CI system if there is none or
> possibly use GNOME continuous if applicable. Definitely open to ideas
> here.

We actually already have a server running Jenkins at
https://build.gimp.org/ for CI. This said, there is currently only one
administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
and depending on his personal schedule (voluntary contributions), we
happened to have extended periods of time (sometimes up to months)
with the continuous integration broken.

Therefore I guess we would be happy to cooperate. You should get in
touch with Sam. What we discussed recently with Sam was:

1/ We'd like more administrators to share the work because when the
build server gets broken for months without anyone able to do anything
about it, that sucks. And such unreliability makes it useless for even
thinking about more advanced uses.

2/ We'd like to have as much of the CI process, scripts, and
everything documented (probably in a versionned repository) so that
developers are able to at least understand, access and maintain the
system a minimum when system admins disappear (less a problem with
several admins of course), and so that the job can be passed along
when needed. I'd like to avoid black box issues.

Basically our first goal is to make our system more reliable and
transparent. These are our main worries right now regarding CI.

> As for coding style we are quite happy users of python Behave [1]
> framework in not only GNOME projects using Dogtail [2] over a11y layer
> or some kind of expect [3] if tests are cli based. For the code
> readability and easiness to code we do use python to connect all these
> together.
> A good example of such code is in gnome-calculator [4] in feature files
> or in gnome-boxes [5].

I think, us developers, are opened to ideas improving our continuous
integration, on server side and in new tests in our build system. Just
propose us what you have in mind.

Once again, I think what really matters to us is reliability: if
something is done, it must be meaningful, maintained and not break
tomorrow. CI is meant to help development, not become a burden to us.
:-)
Obviously contributions from RedHat, I would expect some good level of
maintenance. So we are definitely interested.

> If you have any ideas where our cooperation should start or if you have
> something ready and just not visible to us please point me to the right
> direction.

Well you are welcome to propose us something, on the mailing list, or
through a bug report… And probably coming discuss this on IRC (#gimp
on irc.gimp.org) would be a first step.
The point is that any idea on this topic will rather be your level of
expertise (or Sam's) than ours, so we are open to suggestions.

Jehan



--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Jehan Pagès
Hello Vladimir,

Unless mistaken, we never had any follow-up on your help proposition.
We are still very interested in any help on automatic testing
procedures. Our current continuous builds have been really shaky these
last months, with server issues for months at a time, and such. We
would appreciate some stable and reliable CI. Even more now that GIMP
2.10 release is approaching fast.

Are you still interested by this topic at Red Hat?
We would welcome any collaboration on the topic. :-)
Thanks!

Jehan


On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:

> Hi Vladimir,
>
> On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
>> Hi all,
>> we (at Red Hat) are very interested in GIMP as we do use it and we also
>> do test it (but not the latests releases). We would like to start or
>> participate in an automated testing efforts of upstream releases or
>> possibly master branch. I am not sure if you have anything ready for
>> automated testing of latest code but I wasn't able to find anything. We
>> do have some basic test set in-house but coverage is really far away
>> from ideal and as we have some resources to invest it would be nice to
>> properly cooperate in upstream directly.
>> We would be quite interested to set up a CI system if there is none or
>> possibly use GNOME continuous if applicable. Definitely open to ideas
>> here.
>
> We actually already have a server running Jenkins at
> https://build.gimp.org/ for CI. This said, there is currently only one
> administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
> and depending on his personal schedule (voluntary contributions), we
> happened to have extended periods of time (sometimes up to months)
> with the continuous integration broken.
>
> Therefore I guess we would be happy to cooperate. You should get in
> touch with Sam. What we discussed recently with Sam was:
>
> 1/ We'd like more administrators to share the work because when the
> build server gets broken for months without anyone able to do anything
> about it, that sucks. And such unreliability makes it useless for even
> thinking about more advanced uses.
>
> 2/ We'd like to have as much of the CI process, scripts, and
> everything documented (probably in a versionned repository) so that
> developers are able to at least understand, access and maintain the
> system a minimum when system admins disappear (less a problem with
> several admins of course), and so that the job can be passed along
> when needed. I'd like to avoid black box issues.
>
> Basically our first goal is to make our system more reliable and
> transparent. These are our main worries right now regarding CI.
>
>> As for coding style we are quite happy users of python Behave [1]
>> framework in not only GNOME projects using Dogtail [2] over a11y layer
>> or some kind of expect [3] if tests are cli based. For the code
>> readability and easiness to code we do use python to connect all these
>> together.
>> A good example of such code is in gnome-calculator [4] in feature files
>> or in gnome-boxes [5].
>
> I think, us developers, are opened to ideas improving our continuous
> integration, on server side and in new tests in our build system. Just
> propose us what you have in mind.
>
> Once again, I think what really matters to us is reliability: if
> something is done, it must be meaningful, maintained and not break
> tomorrow. CI is meant to help development, not become a burden to us.
> :-)
> Obviously contributions from RedHat, I would expect some good level of
> maintenance. So we are definitely interested.
>
>> If you have any ideas where our cooperation should start or if you have
>> something ready and just not visible to us please point me to the right
>> direction.
>
> Well you are welcome to propose us something, on the mailing list, or
> through a bug report… And probably coming discuss this on IRC (#gimp
> on irc.gimp.org) would be a first step.
> The point is that any idea on this topic will rather be your level of
> expertise (or Sam's) than ours, so we are open to suggestions.
>
> Jehan
>
>> Looking forward to hearing from you,
>> Vladimir
>>
>> [1] http://pythonhosted.org/behave/tutorial.html
>> [2] https://fedorahosted.org/dogtail/
>> [3] https://pexpect.readthedocs.io/en/stable/
>> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
>> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
>>
>> _______________________________________________
>> gimp-developer-list mailing list
>> List address:    [hidden email]
>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
>
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Patreon: https://patreon.com/zemarmot
> Tipeee: https://www.tipeee.com/zemarmot



--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

gregory grey
Hiya, I'm awaiting feedback from Sam on the same topic here. Count me
in on any related activities.

One of my questions would be if anyone ever considered using Travis
CI, which is taken case of by themselves and is used by lots of
opensource projects.

2017-02-09 23:52 GMT+01:00 Jehan Pagès <[hidden email]>:

> Hello Vladimir,
>
> Unless mistaken, we never had any follow-up on your help proposition.
> We are still very interested in any help on automatic testing
> procedures. Our current continuous builds have been really shaky these
> last months, with server issues for months at a time, and such. We
> would appreciate some stable and reliable CI. Even more now that GIMP
> 2.10 release is approaching fast.
>
> Are you still interested by this topic at Red Hat?
> We would welcome any collaboration on the topic. :-)
> Thanks!
>
> Jehan
>
>
> On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:
>> Hi Vladimir,
>>
>> On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
>>> Hi all,
>>> we (at Red Hat) are very interested in GIMP as we do use it and we also
>>> do test it (but not the latests releases). We would like to start or
>>> participate in an automated testing efforts of upstream releases or
>>> possibly master branch. I am not sure if you have anything ready for
>>> automated testing of latest code but I wasn't able to find anything. We
>>> do have some basic test set in-house but coverage is really far away
>>> from ideal and as we have some resources to invest it would be nice to
>>> properly cooperate in upstream directly.
>>> We would be quite interested to set up a CI system if there is none or
>>> possibly use GNOME continuous if applicable. Definitely open to ideas
>>> here.
>>
>> We actually already have a server running Jenkins at
>> https://build.gimp.org/ for CI. This said, there is currently only one
>> administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
>> and depending on his personal schedule (voluntary contributions), we
>> happened to have extended periods of time (sometimes up to months)
>> with the continuous integration broken.
>>
>> Therefore I guess we would be happy to cooperate. You should get in
>> touch with Sam. What we discussed recently with Sam was:
>>
>> 1/ We'd like more administrators to share the work because when the
>> build server gets broken for months without anyone able to do anything
>> about it, that sucks. And such unreliability makes it useless for even
>> thinking about more advanced uses.
>>
>> 2/ We'd like to have as much of the CI process, scripts, and
>> everything documented (probably in a versionned repository) so that
>> developers are able to at least understand, access and maintain the
>> system a minimum when system admins disappear (less a problem with
>> several admins of course), and so that the job can be passed along
>> when needed. I'd like to avoid black box issues.
>>
>> Basically our first goal is to make our system more reliable and
>> transparent. These are our main worries right now regarding CI.
>>
>>> As for coding style we are quite happy users of python Behave [1]
>>> framework in not only GNOME projects using Dogtail [2] over a11y layer
>>> or some kind of expect [3] if tests are cli based. For the code
>>> readability and easiness to code we do use python to connect all these
>>> together.
>>> A good example of such code is in gnome-calculator [4] in feature files
>>> or in gnome-boxes [5].
>>
>> I think, us developers, are opened to ideas improving our continuous
>> integration, on server side and in new tests in our build system. Just
>> propose us what you have in mind.
>>
>> Once again, I think what really matters to us is reliability: if
>> something is done, it must be meaningful, maintained and not break
>> tomorrow. CI is meant to help development, not become a burden to us.
>> :-)
>> Obviously contributions from RedHat, I would expect some good level of
>> maintenance. So we are definitely interested.
>>
>>> If you have any ideas where our cooperation should start or if you have
>>> something ready and just not visible to us please point me to the right
>>> direction.
>>
>> Well you are welcome to propose us something, on the mailing list, or
>> through a bug report… And probably coming discuss this on IRC (#gimp
>> on irc.gimp.org) would be a first step.
>> The point is that any idea on this topic will rather be your level of
>> expertise (or Sam's) than ours, so we are open to suggestions.
>>
>> Jehan
>>
>>> Looking forward to hearing from you,
>>> Vladimir
>>>
>>> [1] http://pythonhosted.org/behave/tutorial.html
>>> [2] https://fedorahosted.org/dogtail/
>>> [3] https://pexpect.readthedocs.io/en/stable/
>>> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
>>> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
>>>
>>> _______________________________________________
>>> gimp-developer-list mailing list
>>> List address:    [hidden email]
>>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>
>>
>>
>> --
>> ZeMarmot open animation film
>> http://film.zemarmot.net
>> Patreon: https://patreon.com/zemarmot
>> Tipeee: https://www.tipeee.com/zemarmot
>
>
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Patreon: https://patreon.com/zemarmot
> Tipeee: https://www.tipeee.com/zemarmot
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [hidden email]
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list



--

http://ror6ax.github.io/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Alexandre Prokoudine
build.gimp.org

10 февр. 2017 г. 11:26 пользователь "gregory grey" <[hidden email]>
написал:

> Hiya, I'm awaiting feedback from Sam on the same topic here. Count me
> in on any related activities.
>
> One of my questions would be if anyone ever considered using Travis
> CI, which is taken case of by themselves and is used by lots of
> opensource projects.
>
> 2017-02-09 23:52 GMT+01:00 Jehan Pagès <[hidden email]>:
> > Hello Vladimir,
> >
> > Unless mistaken, we never had any follow-up on your help proposition.
> > We are still very interested in any help on automatic testing
> > procedures. Our current continuous builds have been really shaky these
> > last months, with server issues for months at a time, and such. We
> > would appreciate some stable and reliable CI. Even more now that GIMP
> > 2.10 release is approaching fast.
> >
> > Are you still interested by this topic at Red Hat?
> > We would welcome any collaboration on the topic. :-)
> > Thanks!
> >
> > Jehan
> >
> >
> > On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]>
> wrote:
> >> Hi Vladimir,
> >>
> >> On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]>
> wrote:
> >>> Hi all,
> >>> we (at Red Hat) are very interested in GIMP as we do use it and we also
> >>> do test it (but not the latests releases). We would like to start or
> >>> participate in an automated testing efforts of upstream releases or
> >>> possibly master branch. I am not sure if you have anything ready for
> >>> automated testing of latest code but I wasn't able to find anything. We
> >>> do have some basic test set in-house but coverage is really far away
> >>> from ideal and as we have some resources to invest it would be nice to
> >>> properly cooperate in upstream directly.
> >>> We would be quite interested to set up a CI system if there is none or
> >>> possibly use GNOME continuous if applicable. Definitely open to ideas
> >>> here.
> >>
> >> We actually already have a server running Jenkins at
> >> https://build.gimp.org/ for CI. This said, there is currently only one
> >> administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
> >> and depending on his personal schedule (voluntary contributions), we
> >> happened to have extended periods of time (sometimes up to months)
> >> with the continuous integration broken.
> >>
> >> Therefore I guess we would be happy to cooperate. You should get in
> >> touch with Sam. What we discussed recently with Sam was:
> >>
> >> 1/ We'd like more administrators to share the work because when the
> >> build server gets broken for months without anyone able to do anything
> >> about it, that sucks. And such unreliability makes it useless for even
> >> thinking about more advanced uses.
> >>
> >> 2/ We'd like to have as much of the CI process, scripts, and
> >> everything documented (probably in a versionned repository) so that
> >> developers are able to at least understand, access and maintain the
> >> system a minimum when system admins disappear (less a problem with
> >> several admins of course), and so that the job can be passed along
> >> when needed. I'd like to avoid black box issues.
> >>
> >> Basically our first goal is to make our system more reliable and
> >> transparent. These are our main worries right now regarding CI.
> >>
> >>> As for coding style we are quite happy users of python Behave [1]
> >>> framework in not only GNOME projects using Dogtail [2] over a11y layer
> >>> or some kind of expect [3] if tests are cli based. For the code
> >>> readability and easiness to code we do use python to connect all these
> >>> together.
> >>> A good example of such code is in gnome-calculator [4] in feature files
> >>> or in gnome-boxes [5].
> >>
> >> I think, us developers, are opened to ideas improving our continuous
> >> integration, on server side and in new tests in our build system. Just
> >> propose us what you have in mind.
> >>
> >> Once again, I think what really matters to us is reliability: if
> >> something is done, it must be meaningful, maintained and not break
> >> tomorrow. CI is meant to help development, not become a burden to us.
> >> :-)
> >> Obviously contributions from RedHat, I would expect some good level of
> >> maintenance. So we are definitely interested.
> >>
> >>> If you have any ideas where our cooperation should start or if you have
> >>> something ready and just not visible to us please point me to the right
> >>> direction.
> >>
> >> Well you are welcome to propose us something, on the mailing list, or
> >> through a bug report… And probably coming discuss this on IRC (#gimp
> >> on irc.gimp.org) would be a first step.
> >> The point is that any idea on this topic will rather be your level of
> >> expertise (or Sam's) than ours, so we are open to suggestions.
> >>
> >> Jehan
> >>
> >>> Looking forward to hearing from you,
> >>> Vladimir
> >>>
> >>> [1] http://pythonhosted.org/behave/tutorial.html
> >>> [2] https://fedorahosted.org/dogtail/
> >>> [3] https://pexpect.readthedocs.io/en/stable/
> >>> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
> >>> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
> >>>
> >>> _______________________________________________
> >>> gimp-developer-list mailing list
> >>> List address:    [hidden email]
> >>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-
> developer-list
> >>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
> >>
> >>
> >>
> >> --
> >> ZeMarmot open animation film
> >> http://film.zemarmot.net
> >> Patreon: https://patreon.com/zemarmot
> >> Tipeee: https://www.tipeee.com/zemarmot
> >
> >
> >
> > --
> > ZeMarmot open animation film
> > http://film.zemarmot.net
> > Patreon: https://patreon.com/zemarmot
> > Tipeee: https://www.tipeee.com/zemarmot
> > _______________________________________________
> > gimp-developer-list mailing list
> > List address:    [hidden email]
> > List membership: https://mail.gnome.org/mailman/listinfo/gimp-
> developer-list
> > List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
>
>
> --
>
> http://ror6ax.github.io/
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [hidden email]
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-
> developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Vladimír Beneš
In reply to this post by Jehan Pagès
Hi Jehan,

On Thu, 2017-02-09 at 23:52 +0100, Jehan Pagès wrote:

> Hello Vladimir,
>
> Unless mistaken, we never had any follow-up on your help proposition.
> We are still very interested in any help on automatic testing
> procedures. Our current continuous builds have been really shaky these
> last months, with server issues for months at a time, and such. We
> would appreciate some stable and reliable CI. Even more now that GIMP
> 2.10 release is approaching fast.
>
> Are you still interested by this topic at Red Hat?
> We would welcome any collaboration on the topic. :-)
> Thanks!
>

I am really sorry that I haven't responded. We had some personal changes
in the team and it somehow slipped under the table.

Anyways, we are in the process of moving some of our automation to CICO
(CentOS CI) which seems to be pretty stable and what's more interesting,
it's public! https://ci.centos.org/

I have started with NetworkManager
https://github.com/NetworkManager/NetworkManager-ci

It should be pretty well integrated with github and ansible and it's
possible to build other non CentOS environments on top of CentOS
installation (via vagrant or so). I think it's just a matter of being
able to compile without special efforts, right? CentOS and epel should
be pretty stable env.

I will discuss this more with my manager and we will prioritize things
accordingly. I think that moving our code a bit more towards community
(and into public) and you maybe moving your code to reach more stability
to some other env can intersect in CICO. Who knows! CICO seems to be
pretty beefy and equipped with hundreds of bare-metal machines and also
in the process to enable cloud (openstack based) provisioning soon.  

I will keep you updated how NM goes and we can do something about GIMP
too. The biggest concern in our team here was the C code. We are not
much into C as we are pretty more python/gherkin/shell oriented. But if
sanity test code is actively maintained by developers we can deliver
some more integration tests on top of it ideally in the same CI system.

Does it make sense? Ideas?
Vladimir


> Jehan
>
>
> On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:
> > Hi Vladimir,
> >
> > On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
> >> Hi all,
> >> we (at Red Hat) are very interested in GIMP as we do use it and we also
> >> do test it (but not the latests releases). We would like to start or
> >> participate in an automated testing efforts of upstream releases or
> >> possibly master branch. I am not sure if you have anything ready for
> >> automated testing of latest code but I wasn't able to find anything. We
> >> do have some basic test set in-house but coverage is really far away
> >> from ideal and as we have some resources to invest it would be nice to
> >> properly cooperate in upstream directly.
> >> We would be quite interested to set up a CI system if there is none or
> >> possibly use GNOME continuous if applicable. Definitely open to ideas
> >> here.
> >
> > We actually already have a server running Jenkins at
> > https://build.gimp.org/ for CI. This said, there is currently only one
> > administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
> > and depending on his personal schedule (voluntary contributions), we
> > happened to have extended periods of time (sometimes up to months)
> > with the continuous integration broken.
> >
> > Therefore I guess we would be happy to cooperate. You should get in
> > touch with Sam. What we discussed recently with Sam was:
> >
> > 1/ We'd like more administrators to share the work because when the
> > build server gets broken for months without anyone able to do anything
> > about it, that sucks. And such unreliability makes it useless for even
> > thinking about more advanced uses.
> >
> > 2/ We'd like to have as much of the CI process, scripts, and
> > everything documented (probably in a versionned repository) so that
> > developers are able to at least understand, access and maintain the
> > system a minimum when system admins disappear (less a problem with
> > several admins of course), and so that the job can be passed along
> > when needed. I'd like to avoid black box issues.
> >
> > Basically our first goal is to make our system more reliable and
> > transparent. These are our main worries right now regarding CI.
> >
> >> As for coding style we are quite happy users of python Behave [1]
> >> framework in not only GNOME projects using Dogtail [2] over a11y layer
> >> or some kind of expect [3] if tests are cli based. For the code
> >> readability and easiness to code we do use python to connect all these
> >> together.
> >> A good example of such code is in gnome-calculator [4] in feature files
> >> or in gnome-boxes [5].
> >
> > I think, us developers, are opened to ideas improving our continuous
> > integration, on server side and in new tests in our build system. Just
> > propose us what you have in mind.
> >
> > Once again, I think what really matters to us is reliability: if
> > something is done, it must be meaningful, maintained and not break
> > tomorrow. CI is meant to help development, not become a burden to us.
> > :-)
> > Obviously contributions from RedHat, I would expect some good level of
> > maintenance. So we are definitely interested.
> >
> >> If you have any ideas where our cooperation should start or if you have
> >> something ready and just not visible to us please point me to the right
> >> direction.
> >
> > Well you are welcome to propose us something, on the mailing list, or
> > through a bug report… And probably coming discuss this on IRC (#gimp
> > on irc.gimp.org) would be a first step.
> > The point is that any idea on this topic will rather be your level of
> > expertise (or Sam's) than ours, so we are open to suggestions.
> >
> > Jehan
> >
> >> Looking forward to hearing from you,
> >> Vladimir
> >>
> >> [1] http://pythonhosted.org/behave/tutorial.html
> >> [2] https://fedorahosted.org/dogtail/
> >> [3] https://pexpect.readthedocs.io/en/stable/
> >> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
> >> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
> >>
> >> _______________________________________________
> >> gimp-developer-list mailing list
> >> List address:    [hidden email]
> >> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >> List archives:   https://mail.gnome.org/archives/gimp-developer-list
> >
> >
> >
> > --
> > ZeMarmot open animation film
> > http://film.zemarmot.net
> > Patreon: https://patreon.com/zemarmot
> > Tipeee: https://www.tipeee.com/zemarmot
>
>
>


_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Vladimír Beneš
In reply to this post by gregory grey
On Fri, 2017-02-10 at 09:26 +0100, gregory grey wrote:
> Hiya, I'm awaiting feedback from Sam on the same topic here. Count me
> in on any related activities.
>
> One of my questions would be if anyone ever considered using Travis
> CI, which is taken case of by themselves and is used by lots of
> opensource projects.
>

in NM area we do use Travis to check that it always compile after a
commit
https://travis-ci.org/NetworkManager/NetworkManager

Sadly, it's Debian based only (if not mistaken totally) so not much
intersecting Fedora based distro interests :-(.

Vladimir

> 2017-02-09 23:52 GMT+01:00 Jehan Pagès <[hidden email]>:
> > Hello Vladimir,
> >
> > Unless mistaken, we never had any follow-up on your help proposition.
> > We are still very interested in any help on automatic testing
> > procedures. Our current continuous builds have been really shaky these
> > last months, with server issues for months at a time, and such. We
> > would appreciate some stable and reliable CI. Even more now that GIMP
> > 2.10 release is approaching fast.
> >
> > Are you still interested by this topic at Red Hat?
> > We would welcome any collaboration on the topic. :-)
> > Thanks!
> >
> > Jehan
> >
> >
> > On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:
> >> Hi Vladimir,
> >>
> >> On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
> >>> Hi all,
> >>> we (at Red Hat) are very interested in GIMP as we do use it and we also
> >>> do test it (but not the latests releases). We would like to start or
> >>> participate in an automated testing efforts of upstream releases or
> >>> possibly master branch. I am not sure if you have anything ready for
> >>> automated testing of latest code but I wasn't able to find anything. We
> >>> do have some basic test set in-house but coverage is really far away
> >>> from ideal and as we have some resources to invest it would be nice to
> >>> properly cooperate in upstream directly.
> >>> We would be quite interested to set up a CI system if there is none or
> >>> possibly use GNOME continuous if applicable. Definitely open to ideas
> >>> here.
> >>
> >> We actually already have a server running Jenkins at
> >> https://build.gimp.org/ for CI. This said, there is currently only one
> >> administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
> >> and depending on his personal schedule (voluntary contributions), we
> >> happened to have extended periods of time (sometimes up to months)
> >> with the continuous integration broken.
> >>
> >> Therefore I guess we would be happy to cooperate. You should get in
> >> touch with Sam. What we discussed recently with Sam was:
> >>
> >> 1/ We'd like more administrators to share the work because when the
> >> build server gets broken for months without anyone able to do anything
> >> about it, that sucks. And such unreliability makes it useless for even
> >> thinking about more advanced uses.
> >>
> >> 2/ We'd like to have as much of the CI process, scripts, and
> >> everything documented (probably in a versionned repository) so that
> >> developers are able to at least understand, access and maintain the
> >> system a minimum when system admins disappear (less a problem with
> >> several admins of course), and so that the job can be passed along
> >> when needed. I'd like to avoid black box issues.
> >>
> >> Basically our first goal is to make our system more reliable and
> >> transparent. These are our main worries right now regarding CI.
> >>
> >>> As for coding style we are quite happy users of python Behave [1]
> >>> framework in not only GNOME projects using Dogtail [2] over a11y layer
> >>> or some kind of expect [3] if tests are cli based. For the code
> >>> readability and easiness to code we do use python to connect all these
> >>> together.
> >>> A good example of such code is in gnome-calculator [4] in feature files
> >>> or in gnome-boxes [5].
> >>
> >> I think, us developers, are opened to ideas improving our continuous
> >> integration, on server side and in new tests in our build system. Just
> >> propose us what you have in mind.
> >>
> >> Once again, I think what really matters to us is reliability: if
> >> something is done, it must be meaningful, maintained and not break
> >> tomorrow. CI is meant to help development, not become a burden to us.
> >> :-)
> >> Obviously contributions from RedHat, I would expect some good level of
> >> maintenance. So we are definitely interested.
> >>
> >>> If you have any ideas where our cooperation should start or if you have
> >>> something ready and just not visible to us please point me to the right
> >>> direction.
> >>
> >> Well you are welcome to propose us something, on the mailing list, or
> >> through a bug report… And probably coming discuss this on IRC (#gimp
> >> on irc.gimp.org) would be a first step.
> >> The point is that any idea on this topic will rather be your level of
> >> expertise (or Sam's) than ours, so we are open to suggestions.
> >>
> >> Jehan
> >>
> >>> Looking forward to hearing from you,
> >>> Vladimir
> >>>
> >>> [1] http://pythonhosted.org/behave/tutorial.html
> >>> [2] https://fedorahosted.org/dogtail/
> >>> [3] https://pexpect.readthedocs.io/en/stable/
> >>> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
> >>> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
> >>>
> >>> _______________________________________________
> >>> gimp-developer-list mailing list
> >>> List address:    [hidden email]
> >>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
> >>
> >>
> >>
> >> --
> >> ZeMarmot open animation film
> >> http://film.zemarmot.net
> >> Patreon: https://patreon.com/zemarmot
> >> Tipeee: https://www.tipeee.com/zemarmot
> >
> >
> >
> > --
> > ZeMarmot open animation film
> > http://film.zemarmot.net
> > Patreon: https://patreon.com/zemarmot
> > Tipeee: https://www.tipeee.com/zemarmot
> > _______________________________________________
> > gimp-developer-list mailing list
> > List address:    [hidden email]
> > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
>
>


_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

gregory grey
I know about build.gimp.org.

I just wanted to raise this question to the attention of the team - of
whether there is a need to support own CI if security is not an
issue.It is literally only reason people do that now when we have
travis-ci.org/https://circleci.com/etc.Travis is even free for
opensource projects.

https://build.gimp.org/plugin/disk-usage/ looks pretty full to me, for
example. External CI do not have problems with that.

Also, build declaration files are much more manageable than pages with
tabs. Trust me, I'm dealing with huge builds every day.

2017-02-10 10:05 GMT+01:00 Vladimír Beneš <[hidden email]>:

> On Fri, 2017-02-10 at 09:26 +0100, gregory grey wrote:
>> Hiya, I'm awaiting feedback from Sam on the same topic here. Count me
>> in on any related activities.
>>
>> One of my questions would be if anyone ever considered using Travis
>> CI, which is taken case of by themselves and is used by lots of
>> opensource projects.
>>
>
> in NM area we do use Travis to check that it always compile after a
> commit
> https://travis-ci.org/NetworkManager/NetworkManager
>
> Sadly, it's Debian based only (if not mistaken totally) so not much
> intersecting Fedora based distro interests :-(.
>
> Vladimir
>
>> 2017-02-09 23:52 GMT+01:00 Jehan Pagès <[hidden email]>:
>> > Hello Vladimir,
>> >
>> > Unless mistaken, we never had any follow-up on your help proposition.
>> > We are still very interested in any help on automatic testing
>> > procedures. Our current continuous builds have been really shaky these
>> > last months, with server issues for months at a time, and such. We
>> > would appreciate some stable and reliable CI. Even more now that GIMP
>> > 2.10 release is approaching fast.
>> >
>> > Are you still interested by this topic at Red Hat?
>> > We would welcome any collaboration on the topic. :-)
>> > Thanks!
>> >
>> > Jehan
>> >
>> >
>> > On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:
>> >> Hi Vladimir,
>> >>
>> >> On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
>> >>> Hi all,
>> >>> we (at Red Hat) are very interested in GIMP as we do use it and we also
>> >>> do test it (but not the latests releases). We would like to start or
>> >>> participate in an automated testing efforts of upstream releases or
>> >>> possibly master branch. I am not sure if you have anything ready for
>> >>> automated testing of latest code but I wasn't able to find anything. We
>> >>> do have some basic test set in-house but coverage is really far away
>> >>> from ideal and as we have some resources to invest it would be nice to
>> >>> properly cooperate in upstream directly.
>> >>> We would be quite interested to set up a CI system if there is none or
>> >>> possibly use GNOME continuous if applicable. Definitely open to ideas
>> >>> here.
>> >>
>> >> We actually already have a server running Jenkins at
>> >> https://build.gimp.org/ for CI. This said, there is currently only one
>> >> administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
>> >> and depending on his personal schedule (voluntary contributions), we
>> >> happened to have extended periods of time (sometimes up to months)
>> >> with the continuous integration broken.
>> >>
>> >> Therefore I guess we would be happy to cooperate. You should get in
>> >> touch with Sam. What we discussed recently with Sam was:
>> >>
>> >> 1/ We'd like more administrators to share the work because when the
>> >> build server gets broken for months without anyone able to do anything
>> >> about it, that sucks. And such unreliability makes it useless for even
>> >> thinking about more advanced uses.
>> >>
>> >> 2/ We'd like to have as much of the CI process, scripts, and
>> >> everything documented (probably in a versionned repository) so that
>> >> developers are able to at least understand, access and maintain the
>> >> system a minimum when system admins disappear (less a problem with
>> >> several admins of course), and so that the job can be passed along
>> >> when needed. I'd like to avoid black box issues.
>> >>
>> >> Basically our first goal is to make our system more reliable and
>> >> transparent. These are our main worries right now regarding CI.
>> >>
>> >>> As for coding style we are quite happy users of python Behave [1]
>> >>> framework in not only GNOME projects using Dogtail [2] over a11y layer
>> >>> or some kind of expect [3] if tests are cli based. For the code
>> >>> readability and easiness to code we do use python to connect all these
>> >>> together.
>> >>> A good example of such code is in gnome-calculator [4] in feature files
>> >>> or in gnome-boxes [5].
>> >>
>> >> I think, us developers, are opened to ideas improving our continuous
>> >> integration, on server side and in new tests in our build system. Just
>> >> propose us what you have in mind.
>> >>
>> >> Once again, I think what really matters to us is reliability: if
>> >> something is done, it must be meaningful, maintained and not break
>> >> tomorrow. CI is meant to help development, not become a burden to us.
>> >> :-)
>> >> Obviously contributions from RedHat, I would expect some good level of
>> >> maintenance. So we are definitely interested.
>> >>
>> >>> If you have any ideas where our cooperation should start or if you have
>> >>> something ready and just not visible to us please point me to the right
>> >>> direction.
>> >>
>> >> Well you are welcome to propose us something, on the mailing list, or
>> >> through a bug report… And probably coming discuss this on IRC (#gimp
>> >> on irc.gimp.org) would be a first step.
>> >> The point is that any idea on this topic will rather be your level of
>> >> expertise (or Sam's) than ours, so we are open to suggestions.
>> >>
>> >> Jehan
>> >>
>> >>> Looking forward to hearing from you,
>> >>> Vladimir
>> >>>
>> >>> [1] http://pythonhosted.org/behave/tutorial.html
>> >>> [2] https://fedorahosted.org/dogtail/
>> >>> [3] https://pexpect.readthedocs.io/en/stable/
>> >>> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
>> >>> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
>> >>>
>> >>> _______________________________________________
>> >>> gimp-developer-list mailing list
>> >>> List address:    [hidden email]
>> >>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> >>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>> >>
>> >>
>> >>
>> >> --
>> >> ZeMarmot open animation film
>> >> http://film.zemarmot.net
>> >> Patreon: https://patreon.com/zemarmot
>> >> Tipeee: https://www.tipeee.com/zemarmot
>> >
>> >
>> >
>> > --
>> > ZeMarmot open animation film
>> > http://film.zemarmot.net
>> > Patreon: https://patreon.com/zemarmot
>> > Tipeee: https://www.tipeee.com/zemarmot
>> > _______________________________________________
>> > gimp-developer-list mailing list
>> > List address:    [hidden email]
>> > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> > List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>
>>
>>
>
>



--

http://ror6ax.github.io/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Jehan Pagès
Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey <[hidden email]> wrote:

> I know about build.gimp.org.
>
> I just wanted to raise this question to the attention of the team - of
> whether there is a need to support own CI if security is not an
> issue.It is literally only reason people do that now when we have
> travis-ci.org/https://circleci.com/etc.Travis is even free for
> opensource projects.
>
> https://build.gimp.org/plugin/disk-usage/ looks pretty full to me, for
> example. External CI do not have problems with that.

We know of the disk usage issue:
https://bugzilla.gnome.org/show_bug.cgi?id=776631
That's one of the many issues which triggered us into either looking
for alternative solutions or collaboration or whatever you want.
Basically we want something which works, is useful and reliable. The
"need" stops there.

After, which software is it using? I think we don't really care. Now
obviously we'd prefer our whole infrastructure to run on Free
Software. And personally I like self-hosting for full control. But
then there is reality check: it requires contributor time and
administration skills. So in the end, the CI contributor(s) choose. In
the GIMP team, our policy is more or less that the one who *do* are
the one who are in charge of what they do.

Jehan

> Also, build declaration files are much more manageable than pages with
> tabs. Trust me, I'm dealing with huge builds every day.
>
> 2017-02-10 10:05 GMT+01:00 Vladimír Beneš <[hidden email]>:
>> On Fri, 2017-02-10 at 09:26 +0100, gregory grey wrote:
>>> Hiya, I'm awaiting feedback from Sam on the same topic here. Count me
>>> in on any related activities.
>>>
>>> One of my questions would be if anyone ever considered using Travis
>>> CI, which is taken case of by themselves and is used by lots of
>>> opensource projects.
>>>
>>
>> in NM area we do use Travis to check that it always compile after a
>> commit
>> https://travis-ci.org/NetworkManager/NetworkManager
>>
>> Sadly, it's Debian based only (if not mistaken totally) so not much
>> intersecting Fedora based distro interests :-(.
>>
>> Vladimir
>>
>>> 2017-02-09 23:52 GMT+01:00 Jehan Pagès <[hidden email]>:
>>> > Hello Vladimir,
>>> >
>>> > Unless mistaken, we never had any follow-up on your help proposition.
>>> > We are still very interested in any help on automatic testing
>>> > procedures. Our current continuous builds have been really shaky these
>>> > last months, with server issues for months at a time, and such. We
>>> > would appreciate some stable and reliable CI. Even more now that GIMP
>>> > 2.10 release is approaching fast.
>>> >
>>> > Are you still interested by this topic at Red Hat?
>>> > We would welcome any collaboration on the topic. :-)
>>> > Thanks!
>>> >
>>> > Jehan
>>> >
>>> >
>>> > On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:
>>> >> Hi Vladimir,
>>> >>
>>> >> On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
>>> >>> Hi all,
>>> >>> we (at Red Hat) are very interested in GIMP as we do use it and we also
>>> >>> do test it (but not the latests releases). We would like to start or
>>> >>> participate in an automated testing efforts of upstream releases or
>>> >>> possibly master branch. I am not sure if you have anything ready for
>>> >>> automated testing of latest code but I wasn't able to find anything. We
>>> >>> do have some basic test set in-house but coverage is really far away
>>> >>> from ideal and as we have some resources to invest it would be nice to
>>> >>> properly cooperate in upstream directly.
>>> >>> We would be quite interested to set up a CI system if there is none or
>>> >>> possibly use GNOME continuous if applicable. Definitely open to ideas
>>> >>> here.
>>> >>
>>> >> We actually already have a server running Jenkins at
>>> >> https://build.gimp.org/ for CI. This said, there is currently only one
>>> >> administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
>>> >> and depending on his personal schedule (voluntary contributions), we
>>> >> happened to have extended periods of time (sometimes up to months)
>>> >> with the continuous integration broken.
>>> >>
>>> >> Therefore I guess we would be happy to cooperate. You should get in
>>> >> touch with Sam. What we discussed recently with Sam was:
>>> >>
>>> >> 1/ We'd like more administrators to share the work because when the
>>> >> build server gets broken for months without anyone able to do anything
>>> >> about it, that sucks. And such unreliability makes it useless for even
>>> >> thinking about more advanced uses.
>>> >>
>>> >> 2/ We'd like to have as much of the CI process, scripts, and
>>> >> everything documented (probably in a versionned repository) so that
>>> >> developers are able to at least understand, access and maintain the
>>> >> system a minimum when system admins disappear (less a problem with
>>> >> several admins of course), and so that the job can be passed along
>>> >> when needed. I'd like to avoid black box issues.
>>> >>
>>> >> Basically our first goal is to make our system more reliable and
>>> >> transparent. These are our main worries right now regarding CI.
>>> >>
>>> >>> As for coding style we are quite happy users of python Behave [1]
>>> >>> framework in not only GNOME projects using Dogtail [2] over a11y layer
>>> >>> or some kind of expect [3] if tests are cli based. For the code
>>> >>> readability and easiness to code we do use python to connect all these
>>> >>> together.
>>> >>> A good example of such code is in gnome-calculator [4] in feature files
>>> >>> or in gnome-boxes [5].
>>> >>
>>> >> I think, us developers, are opened to ideas improving our continuous
>>> >> integration, on server side and in new tests in our build system. Just
>>> >> propose us what you have in mind.
>>> >>
>>> >> Once again, I think what really matters to us is reliability: if
>>> >> something is done, it must be meaningful, maintained and not break
>>> >> tomorrow. CI is meant to help development, not become a burden to us.
>>> >> :-)
>>> >> Obviously contributions from RedHat, I would expect some good level of
>>> >> maintenance. So we are definitely interested.
>>> >>
>>> >>> If you have any ideas where our cooperation should start or if you have
>>> >>> something ready and just not visible to us please point me to the right
>>> >>> direction.
>>> >>
>>> >> Well you are welcome to propose us something, on the mailing list, or
>>> >> through a bug report… And probably coming discuss this on IRC (#gimp
>>> >> on irc.gimp.org) would be a first step.
>>> >> The point is that any idea on this topic will rather be your level of
>>> >> expertise (or Sam's) than ours, so we are open to suggestions.
>>> >>
>>> >> Jehan
>>> >>
>>> >>> Looking forward to hearing from you,
>>> >>> Vladimir
>>> >>>
>>> >>> [1] http://pythonhosted.org/behave/tutorial.html
>>> >>> [2] https://fedorahosted.org/dogtail/
>>> >>> [3] https://pexpect.readthedocs.io/en/stable/
>>> >>> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
>>> >>> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
>>> >>>
>>> >>> _______________________________________________
>>> >>> gimp-developer-list mailing list
>>> >>> List address:    [hidden email]
>>> >>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> >>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> ZeMarmot open animation film
>>> >> http://film.zemarmot.net
>>> >> Patreon: https://patreon.com/zemarmot
>>> >> Tipeee: https://www.tipeee.com/zemarmot
>>> >
>>> >
>>> >
>>> > --
>>> > ZeMarmot open animation film
>>> > http://film.zemarmot.net
>>> > Patreon: https://patreon.com/zemarmot
>>> > Tipeee: https://www.tipeee.com/zemarmot
>>> > _______________________________________________
>>> > gimp-developer-list mailing list
>>> > List address:    [hidden email]
>>> > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> > List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>>
>>>
>>>
>>
>>
>
>
>
> --
>
> http://ror6ax.github.io/



--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GIMP testing cooperation

Jehan Pagès
In reply to this post by Vladimír Beneš
Hi,

On Fri, Feb 10, 2017 at 10:02 AM, Vladimír Beneš <[hidden email]> wrote:

> Hi Jehan,
>
> On Thu, 2017-02-09 at 23:52 +0100, Jehan Pagès wrote:
>> Hello Vladimir,
>>
>> Unless mistaken, we never had any follow-up on your help proposition.
>> We are still very interested in any help on automatic testing
>> procedures. Our current continuous builds have been really shaky these
>> last months, with server issues for months at a time, and such. We
>> would appreciate some stable and reliable CI. Even more now that GIMP
>> 2.10 release is approaching fast.
>>
>> Are you still interested by this topic at Red Hat?
>> We would welcome any collaboration on the topic. :-)
>> Thanks!
>>
>
> I am really sorry that I haven't responded. We had some personal changes
> in the team and it somehow slipped under the table.

No prob.

> Anyways, we are in the process of moving some of our automation to CICO
> (CentOS CI) which seems to be pretty stable and what's more interesting,
> it's public! https://ci.centos.org/

And I see that's Jenkins, which is already what we are using. So I
guess that means it should not be too hard to migrate all our current
builds as is (no?).

> I have started with NetworkManager
> https://github.com/NetworkManager/NetworkManager-ci
>
> It should be pretty well integrated with github and ansible and it's
> possible to build other non CentOS environments on top of CentOS
> installation (via vagrant or so). I think it's just a matter of being
> able to compile without special efforts, right? CentOS and epel should
> be pretty stable env.

Yes compiling, run the tests, send appropriate warnings when a build
fail for us to check logs… Currently we have a IRC bot which tells us
build results (so that we can know immediately when a build fails).
And be reliable. That's the base. :-)

Just to be sure, you are not only proposing us an infrastructure, but
also to maintain the builds, right?

Just the infrastructure would already be awesome, but what we are
especially lacking are contributors and active CI maintainers. As
often developers are not really interested into spending too long on
administrating CI servers, though we definitely appreciate that there
is one! So we really hope your proposition includes maintaining the CI
instance, and if a build breaks for non-code reason (or at least we
think it's not the code!), someone on your side can look into it
quickly. :-)

Of course we'd still appreciate if we can have logins to be able to
log into the CI instance, though we are definitely not planning into
interfering much with the build maintainers.

> I will discuss this more with my manager and we will prioritize things
> accordingly. I think that moving our code a bit more towards community
> (and into public) and you maybe moving your code to reach more stability
> to some other env can intersect in CICO. Who knows! CICO seems to be
> pretty beefy and equipped with hundreds of bare-metal machines and also
> in the process to enable cloud (openstack based) provisioning soon.

Looks very nice. I hope that will work out!

> I will keep you updated how NM goes and we can do something about GIMP
> too. The biggest concern in our team here was the C code. We are not
> much into C as we are pretty more python/gherkin/shell oriented. But if
> sanity test code is actively maintained by developers we can deliver
> some more integration tests on top of it ideally in the same CI system.

Our code is actively maintained. Our test process could be better, but
we do make sure tests always pass and take it seriously (our current
CI does a make check and we fix any broken tests as quickly as we can,
upon discovering them).

> Does it make sense? Ideas?

Yes it does completely make sense. On our side, I think we will all
agree that if you can propose us a process to make your team our new
CI maintainers, we'd be happy to. Our contribution logics is really
that doers are in command.

Jehan

P.S.: I think I can create new read users onto our current Jenkins
instance so I could give you access if needed be for exporting jobs or
whatnot.

> Vladimir
>
>
>> Jehan
>>
>>
>> On Tue, Sep 20, 2016 at 2:08 AM, Jehan Pagès <[hidden email]> wrote:
>> > Hi Vladimir,
>> >
>> > On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš <[hidden email]> wrote:
>> >> Hi all,
>> >> we (at Red Hat) are very interested in GIMP as we do use it and we also
>> >> do test it (but not the latests releases). We would like to start or
>> >> participate in an automated testing efforts of upstream releases or
>> >> possibly master branch. I am not sure if you have anything ready for
>> >> automated testing of latest code but I wasn't able to find anything. We
>> >> do have some basic test set in-house but coverage is really far away
>> >> from ideal and as we have some resources to invest it would be nice to
>> >> properly cooperate in upstream directly.
>> >> We would be quite interested to set up a CI system if there is none or
>> >> possibly use GNOME continuous if applicable. Definitely open to ideas
>> >> here.
>> >
>> > We actually already have a server running Jenkins at
>> > https://build.gimp.org/ for CI. This said, there is currently only one
>> > administrator (Sam Gleske, aka "samrocketman" on IRC) for this server,
>> > and depending on his personal schedule (voluntary contributions), we
>> > happened to have extended periods of time (sometimes up to months)
>> > with the continuous integration broken.
>> >
>> > Therefore I guess we would be happy to cooperate. You should get in
>> > touch with Sam. What we discussed recently with Sam was:
>> >
>> > 1/ We'd like more administrators to share the work because when the
>> > build server gets broken for months without anyone able to do anything
>> > about it, that sucks. And such unreliability makes it useless for even
>> > thinking about more advanced uses.
>> >
>> > 2/ We'd like to have as much of the CI process, scripts, and
>> > everything documented (probably in a versionned repository) so that
>> > developers are able to at least understand, access and maintain the
>> > system a minimum when system admins disappear (less a problem with
>> > several admins of course), and so that the job can be passed along
>> > when needed. I'd like to avoid black box issues.
>> >
>> > Basically our first goal is to make our system more reliable and
>> > transparent. These are our main worries right now regarding CI.
>> >
>> >> As for coding style we are quite happy users of python Behave [1]
>> >> framework in not only GNOME projects using Dogtail [2] over a11y layer
>> >> or some kind of expect [3] if tests are cli based. For the code
>> >> readability and easiness to code we do use python to connect all these
>> >> together.
>> >> A good example of such code is in gnome-calculator [4] in feature files
>> >> or in gnome-boxes [5].
>> >
>> > I think, us developers, are opened to ideas improving our continuous
>> > integration, on server side and in new tests in our build system. Just
>> > propose us what you have in mind.
>> >
>> > Once again, I think what really matters to us is reliability: if
>> > something is done, it must be meaningful, maintained and not break
>> > tomorrow. CI is meant to help development, not become a burden to us.
>> > :-)
>> > Obviously contributions from RedHat, I would expect some good level of
>> > maintenance. So we are definitely interested.
>> >
>> >> If you have any ideas where our cooperation should start or if you have
>> >> something ready and just not visible to us please point me to the right
>> >> direction.
>> >
>> > Well you are welcome to propose us something, on the mailing list, or
>> > through a bug report… And probably coming discuss this on IRC (#gimp
>> > on irc.gimp.org) would be a first step.
>> > The point is that any idea on this topic will rather be your level of
>> > expertise (or Sam's) than ours, so we are open to suggestions.
>> >
>> > Jehan
>> >
>> >> Looking forward to hearing from you,
>> >> Vladimir
>> >>
>> >> [1] http://pythonhosted.org/behave/tutorial.html
>> >> [2] https://fedorahosted.org/dogtail/
>> >> [3] https://pexpect.readthedocs.io/en/stable/
>> >> [4] https://git.gnome.org/browse/gnome-calculator/tree/tests
>> >> [5] https://git.gnome.org/browse/gnome-boxes/tree/tests
>> >>
>> >> _______________________________________________
>> >> gimp-developer-list mailing list
>> >> List address:    [hidden email]
>> >> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> >> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>> >
>> >
>> >
>> > --
>> > ZeMarmot open animation film
>> > http://film.zemarmot.net
>> > Patreon: https://patreon.com/zemarmot
>> > Tipeee: https://www.tipeee.com/zemarmot
>>
>>
>>
>
>



--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Loading...