Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš 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: gimp-developer-list@gnome.org 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

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 wrote:

Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš 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: gimp-developer-list@gnome.org 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

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 :

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 wrote:

Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš 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: gimp-developer-list@gnome.org 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: gimp-developer-list@gnome.org 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/

build.gimp.org

10 февр. 2017 г. 11:26 пользователь "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 :

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

wrote:

Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš

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: gimp-developer-list@gnome.org 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: gimp-developer-list@gnome.org 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: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list

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š :

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 :

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 wrote:

Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš 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: gimp-developer-list@gnome.org 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: gimp-developer-list@gnome.org 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/

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey 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š :

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 :

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 wrote:

Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš 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: gimp-developer-list@gnome.org 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: gimp-developer-list@gnome.org 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

Hi,

On Fri, Feb 10, 2017 at 10:02 AM, Vladimír Beneš 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 wrote:

Hi Vladimir,

On Mon, Sep 19, 2016 at 2:33 PM, Vladimír Beneš 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: gimp-developer-list@gnome.org 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

On Fri, Feb 10, 2017 at 6:03 AM, Jehan Pagès wrote:

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey 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

Since I don't appear to be seen as a contributor or "doer" I'm happy to just step down completely and remove myself from the project. Much as I like GIMP I don't really like the tone of the thread.

On Thu, Oct 05, 2017 at 12:15:36AM -0700, Sam Gleske wrote:

On Fri, Feb 10, 2017 at 6:03 AM, Jehan Pagès wrote:

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey 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

Since I don't appear to be seen as a contributor or "doer" I'm happy to just step down completely and remove myself from the project. Much as I like GIMP I don't really like the tone of the thread.

I am not a developer, but I think that there's not any particular "tone" involved here. Many free/open source project are governed by such "do-ocrazy"

http://www.urbandictionary.com/define.php?term=do-ocracy

it is just the way it is because of low number of hands involved... You don't like it? Just do more and talk less and you will find yourself in charge...

--

Marco Ciampa

I know a joke about UDP, but you might not get it.

------------------------

GNU/Linux User #78271 FSFE fellow #364

------------------------

On Thu, Oct 5, 2017 at 10:15 AM, Sam Gleske wrote:

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.

Since I don't appear to be seen as a contributor or "doer" I'm happy to just step down completely and remove myself from the project. Much as I like GIMP I don't really like the tone of the thread.

Sam,

Please help me understand something.

You don't read the mailing list often enough to have participated in the discussion back in February. Well, OK. Life happens. But now that you have the time to read it, you somehow arrive at the conclusion that you are not seen as contributor/doer?

How did you arrive at this conclusion exactly? And what is this overreaction good for?

All _I_ know is that you are the person who has been maintaining Jenkins for the past several years. Sounds like a contributor to _me_.

Alex

Hello Sam,

On Thu, Oct 5, 2017 at 9:15 AM, Sam Gleske wrote:

On Fri, Feb 10, 2017 at 6:03 AM, Jehan Pagès wrote:

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey 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

Since I don't appear to be seen as a contributor or "doer" I'm happy to just step down completely and remove myself from the project. Much as I like GIMP I don't really like the tone of the thread.

I don't really understand what triggers this sudden anger but I see you are quoting one of my last emails. And if that is your trigger, then you got the opposite of its meaning since what it meant is that *you* were the one in charge since *you* are the one who does right now! So whoever who wants something different has to go through you first then help you make things happen.

You are considered a contributor and a doer. That's even what I said in my first email (if you haven't, please read it: https://mail.gnome.org/archives/gimp-developer-list/2016-September/msg00018.html), which was the most important, answering Vladimir and telling him to get in touch with you because you are the one making things happen right now. That's pretty much the definition of both a contributor of the project and a doer.

Now if the problem is that we are welcoming additional administrators who want to help (especially if they could be backed by a big company like RedHat), I don't understand. Having additional administrators won't mean at all that we reject you or anything, quite the contrary (cf. again my first email). But if you absolutely want to be alone to administrate (and if that were your issue here), then yes it is a problem. You don't have all the time of the world to maintain perfectly the server (which is no big deal at all! You also have a life and do this voluntarily. We thank you for this), but several admins together could. Same as we are several developers (fortunately since none of us could maintain GIMP as well as now if we were alone).

Our problem was clear: we have only 1 maintainer for continuous integration and you don't have unlimited time. So having a second person to help could be a good idea. Now if you really leave, we have 0 admins, and even if someone else stepped us, we'd be back at square 1.
So this is it. I really want to make things clear because it seems you have been completely misinterpreting this 1-year old thread. Anyway you are free to choose and we still thank you for all what you have done until now. But just consider things with their proper meaning. :-)

Jehan

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot

On 10/05/2017 04:08 PM, Jehan Pagès wrote:

Hello Sam,

[...]

I don't really understand what triggers this sudden anger but I see you are quoting one of my last emails. And if that is your trigger, then you got the opposite of its meaning since what it meant is that *you* were the one in charge since *you* are the one who does right now! So whoever who wants something different has to go through you first then help you make things happen.

Speaking of which, I think the following is an issue with the build environment:

https://bugzilla.gnome.org/show_bug.cgi?id=787115

P.S. Sam, do you receive Bugzilla notification mails for these bugs?

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

Hey Michael,
I do not get bugzilla notifications on this but I am actually aware of the issue and have been working on it for a few days now since I know gimp-master builds were failing.

On Thu, Oct 5, 2017 at 5:03 PM, Michael Schumacher wrote:

On 10/05/2017 04:08 PM, Jehan Pagès wrote:

Hello Sam,

[...]

I don't really understand what triggers this sudden anger but I see you are quoting one of my last emails. And if that is your trigger, then you got the opposite of its meaning since what it meant is that *you* were the one in charge since *you* are the one who does right now! So whoever who wants something different has to go through you first then help you make things happen.

Speaking of which, I think the following is an issue with the build environment:

https://bugzilla.gnome.org/show_bug.cgi?id=787115

P.S. Sam, do you receive Bugzilla notification mails for these bugs?

-- Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list

Hello gimp-dev and community,
I'd like to apologize for my remarks. I think my pride got in the way a bit and I definitely misunderstood the intent of the thread. Hopefully, my reaction does not turn of RedHat for wanting to contribute. I will take this as an opportunity to reflect on my actions and work to continue to improve myself. I definitely want to be seen as a healthy part of this community and I really do appreciate and love what the GIMP dev team does.

If anybody is interested in joining me as an admin for maintaining the GIMP CI server I encourage anybody to reach out to me regardless of your skill level. Even if you're new to Linux and wish to get better at Linux (zero experience) I'm willing to provide you training and act as a senior for advice in Linux system administration.

I'll try to keep conversation more productive than my first reply to this thread. I just wanted to publicly announce my apology since I started this mess publicly.

Thanks,
SAM

On Thu, Oct 5, 2017 at 7:08 AM, Jehan Pagès wrote:

Hello Sam,

On Thu, Oct 5, 2017 at 9:15 AM, Sam Gleske wrote:

On Fri, Feb 10, 2017 at 6:03 AM, Jehan Pagès

wrote:

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey

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

Since I don't appear to be seen as a contributor or "doer" I'm happy to

just

step down completely and remove myself from the project. Much as I like GIMP I don't really like the tone of the thread.

I don't really understand what triggers this sudden anger but I see you are quoting one of my last emails. And if that is your trigger, then you got the opposite of its meaning since what it meant is that *you* were the one in charge since *you* are the one who does right now! So whoever who wants something different has to go through you first then help you make things happen.

You are considered a contributor and a doer. That's even what I said in my first email (if you haven't, please read it: https://mail.gnome.org/archives/gimp-developer-list/ 2016-September/msg00018.html),
which was the most important, answering Vladimir and telling him to get in touch with you because you are the one making things happen right now. That's pretty much the definition of both a contributor of the project and a doer.

Now if the problem is that we are welcoming additional administrators who want to help (especially if they could be backed by a big company like RedHat), I don't understand. Having additional administrators won't mean at all that we reject you or anything, quite the contrary (cf. again my first email). But if you absolutely want to be alone to administrate (and if that were your issue here), then yes it is a problem. You don't have all the time of the world to maintain perfectly the server (which is no big deal at all! You also have a life and do this voluntarily. We thank you for this), but several admins together could. Same as we are several developers (fortunately since none of us could maintain GIMP as well as now if we were alone).

Our problem was clear: we have only 1 maintainer for continuous integration and you don't have unlimited time. So having a second person to help could be a good idea. Now if you really leave, we have 0 admins, and even if someone else stepped us, we'd be back at square 1.
So this is it. I really want to make things clear because it seems you have been completely misinterpreting this 1-year old thread. Anyway you are free to choose and we still thank you for all what you have done until now. But just consider things with their proper meaning. :-)

Jehan

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot

Hi Sam!

I would be happy to help out if I can. Not sure what I can do, but at least I'll try not to make life harder. ;)

Reach me via email or #gimp.

On Fri, Oct 6, 2017 at 12:30 PM Sam Gleske wrote:

Hello gimp-dev and community,
I'd like to apologize for my remarks. I think my pride got in the way a bit and I definitely misunderstood the intent of the thread. Hopefully, my reaction does not turn of RedHat for wanting to contribute. I will take this as an opportunity to reflect on my actions and work to continue to improve myself. I definitely want to be seen as a healthy part of this community and I really do appreciate and love what the GIMP dev team does.

If anybody is interested in joining me as an admin for maintaining the GIMP CI server I encourage anybody to reach out to me regardless of your skill level. Even if you're new to Linux and wish to get better at Linux (zero experience) I'm willing to provide you training and act as a senior for advice in Linux system administration.

I'll try to keep conversation more productive than my first reply to this thread. I just wanted to publicly announce my apology since I started this mess publicly.

Thanks,
SAM

On Thu, Oct 5, 2017 at 7:08 AM, Jehan Pagès wrote:

Hello Sam,

On Thu, Oct 5, 2017 at 9:15 AM, Sam Gleske

wrote:

On Fri, Feb 10, 2017 at 6:03 AM, Jehan Pagès <

jehan.marmottard@gmail.com

wrote:

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey

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

Since I don't appear to be seen as a contributor or "doer" I'm happy to

just

step down completely and remove myself from the project. Much as I

like

GIMP I don't really like the tone of the thread.

I don't really understand what triggers this sudden anger but I see you are quoting one of my last emails. And if that is your trigger, then you got the opposite of its meaning since what it meant is that *you* were the one in charge since *you* are the one who does right now! So whoever who wants something different has to go through you first then help you make things happen.

You are considered a contributor and a doer. That's even what I said in my first email (if you haven't, please read it: https://mail.gnome.org/archives/gimp-developer-list/ 2016-September/msg00018.html),
which was the most important, answering Vladimir and telling him to get in touch with you because you are the one making things happen right now. That's pretty much the definition of both a contributor of the project and a doer.

Now if the problem is that we are welcoming additional administrators who want to help (especially if they could be backed by a big company like RedHat), I don't understand. Having additional administrators won't mean at all that we reject you or anything, quite the contrary (cf. again my first email). But if you absolutely want to be alone to administrate (and if that were your issue here), then yes it is a problem. You don't have all the time of the world to maintain perfectly the server (which is no big deal at all! You also have a life and do this voluntarily. We thank you for this), but several admins together could. Same as we are several developers (fortunately since none of us could maintain GIMP as well as now if we were alone).

Our problem was clear: we have only 1 maintainer for continuous integration and you don't have unlimited time. So having a second person to help could be a good idea. Now if you really leave, we have 0 admins, and even if someone else stepped us, we'd be back at square 1.
So this is it. I really want to make things clear because it seems you have been completely misinterpreting this 1-year old thread. Anyway you are free to choose and we still thank you for all what you have done until now. But just consider things with their proper meaning. :-)

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: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

https://patdavid.net
GPG: 66D1 7CA6 8088 4874 946D  18BD 67C7 6219 89E9 57AC

On 10/06/17 19:29, Sam Gleske wrote:

If anybody is interested in joining me as an admin for maintaining the GIMP CI server I encourage anybody to reach out to me regardless of your skill level. Even if you're new to Linux and wish to get better at Linux (zero experience) I'm willing to provide you training and act as a senior for advice in Linux system administration.

*steps forward*

I can vouch for Ofnuts not being an awful malicious actor. But I can’t vouch for him not being awful. :D (I kid, I kid).

On Fri, Oct 6, 2017 at 6:19 PM Ofnuts wrote:

On 10/06/17 19:29, Sam Gleske wrote:

If anybody is interested in joining me as an admin for maintaining the

GIMP

CI server I encourage anybody to reach out to me regardless of your skill level. Even if you're new to Linux and wish to get better at Linux (zero experience) I'm willing to provide you training and act as a senior for advice in Linux system administration.

*steps forward*
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

https://patdavid.net
GPG: 66D1 7CA6 8088 4874 946D  18BD 67C7 6219 89E9 57AC

Heh, I've seen ofnuts post before so I don't mind onboarding him.

On Fri, Oct 6, 2017 at 5:10 PM, Pat David wrote:

I can vouch for Ofnuts not being an awful malicious actor. But I can’t vouch for him not being awful. :D (I kid, I kid).

On Fri, Oct 6, 2017 at 6:19 PM Ofnuts wrote:

On 10/06/17 19:29, Sam Gleske wrote:

If anybody is interested in joining me as an admin for maintaining the

GIMP

CI server I encourage anybody to reach out to me regardless of your

skill

level. Even if you're new to Linux and wish to get better at Linux

(zero

experience) I'm willing to provide you training and act as a senior for advice in Linux system administration.

*steps forward*
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

--
https://patdavid.net
GPG: 66D1 7CA6 8088 4874 946D 18BD 67C7 6219 89E9 57AC _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list

Late at night I mercilessly tear bash scripts apart and flog docker containers...

On 10/07/17 02:10, Pat David wrote:

I can vouch for Ofnuts not being an awful malicious actor. But I can’t vouch for him not being awful. :D (I kid, I kid).

Hi!

On Fri, Oct 6, 2017 at 7:29 PM, Sam Gleske wrote:

Hello gimp-dev and community,
I'd like to apologize for my remarks. I think my pride got in the way a bit and I definitely misunderstood the intent of the thread. Hopefully, my reaction does not turn of RedHat for wanting to contribute. I will take this as an opportunity to reflect on my actions and work to continue to improve myself. I definitely want to be seen as a healthy part of this community and I really do appreciate and love what the GIMP dev team does.

If anybody is interested in joining me as an admin for maintaining the GIMP CI server I encourage anybody to reach out to me regardless of your skill level. Even if you're new to Linux and wish to get better at Linux (zero experience) I'm willing to provide you training and act as a senior for advice in Linux system administration.

I'll try to keep conversation more productive than my first reply to this thread. I just wanted to publicly announce my apology since I started this mess publicly.

Hey, no problem. We all have our days of tiredness and misunderstandings. :-) Happy to read you don't leave us just now (and that maybe we'll get more admins soon). ;-)

Jehan

Thanks,
SAM

On Thu, Oct 5, 2017 at 7:08 AM, Jehan Pagès wrote:

Hello Sam,

On Thu, Oct 5, 2017 at 9:15 AM, Sam Gleske wrote:

On Fri, Feb 10, 2017 at 6:03 AM, Jehan Pagès

wrote:

Hi,

On Fri, Feb 10, 2017 at 10:20 AM, gregory grey 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

Since I don't appear to be seen as a contributor or "doer" I'm happy to just
step down completely and remove myself from the project. Much as I like GIMP I don't really like the tone of the thread.

I don't really understand what triggers this sudden anger but I see you are quoting one of my last emails. And if that is your trigger, then you got the opposite of its meaning since what it meant is that *you* were the one in charge since *you* are the one who does right now! So whoever who wants something different has to go through you first then help you make things happen.

You are considered a contributor and a doer. That's even what I said in my first email (if you haven't, please read it:

https://mail.gnome.org/archives/gimp-developer-list/2016-September/msg00018.html), which was the most important, answering Vladimir and telling him to get in touch with you because you are the one making things happen right now. That's pretty much the definition of both a contributor of the project and a doer.

Now if the problem is that we are welcoming additional administrators who want to help (especially if they could be backed by a big company like RedHat), I don't understand. Having additional administrators won't mean at all that we reject you or anything, quite the contrary (cf. again my first email). But if you absolutely want to be alone to administrate (and if that were your issue here), then yes it is a problem. You don't have all the time of the world to maintain perfectly the server (which is no big deal at all! You also have a life and do this voluntarily. We thank you for this), but several admins together could. Same as we are several developers (fortunately since none of us could maintain GIMP as well as now if we were alone).

Our problem was clear: we have only 1 maintainer for continuous integration and you don't have unlimited time. So having a second person to help could be a good idea. Now if you really leave, we have 0 admins, and even if someone else stepped us, we'd be back at square 1.
So this is it. I really want to make things clear because it seems you have been completely misinterpreting this 1-year old thread. Anyway you are free to choose and we still thank you for all what you have done until now. But just consider things with their proper meaning. :-)

Jehan

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

On 10/06/2017 07:25 PM, Sam Gleske wrote:

Hey Michael,

I do not get bugzilla notifications on this

Ah... that is unfortunate. I filed that report a month ago and was assuming that you had been notified by this.

Can you check if your Bugzilla notification settings at

https://bugzilla.gnome.org/userprefs.cgi?tab=email

have the check mark for 'relationship: assignee' and 'new bug created' set?

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD