<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">At the risk of chiming in as a non-developer, I'd observe that I'm not sure that Maria's final question ("will Jenkins be enough") accurately summarizes what I hear as the core take home of this thread. Rather, I think there is a legitimate difference of opinion on:</div><div class="gmail_default" style=""><ol style=""><li style=""><font face="tahoma, sans-serif">Should all OSGeo projects use the same platform (whether it be Jenkins, or Travis, or other tooling)?</font></li><li style=""><font face="tahoma, sans-serif">Or, should projects be free to use the tools that work best from their points-of-view, and in light of the history of those projects?</font></li><li style=""><font face="tahoma, sans-serif">And, there's a subtext of what is "more important", having the "purity" of more open solutions; or the practicality of getting work done with tools that the people involved with projects may be familiar with, or simply prefer?</font></li></ol><div><font face="tahoma, sans-serif">And of course, the overarching question is <i>what should OSGeo do about it?</i> </font></div><div><ul><li><font face="tahoma, sans-serif">Should there be a policy about what tools projects may be <i>required </i>to use?</font></li><li><font face="tahoma, sans-serif">Should OSGeo setup an open platform, that it supervises and makes available (on a voluntary basis) to projects?</font></li><li><font face="tahoma, sans-serif">Should projects be allowed to spend project money on commercial tools (i.e., if they include those expenses in their budgets; and even if some of those moneys come from sources like OSGeo)?</font></li></ul><div><font face="tahoma, sans-serif">I think these bigger issues are the most important part of this thread, and from my reading there is not yet a clear consensus. This seems like an important issue (and policy; and direction statement) for OSGeo/the Board to address.</font></div></div><div><font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif">Count me squarely in the "practicality is important" camp. Indeed, to me producing great, open source software is the end goal. And the people that manage those projects should have a large say in what tools are best for them; as well as the freedom to spend money on those tools when appropriate (and with OSGeo's support). Indeed, there is no such thing as open source purity (well, maybe Stallman approaches that?), as significant parts of the software development ecosystem ranging from hardware to internet access are paid for commercially.</font></div><div><font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif">MT</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 11:05 AM, María Arias de Reyna <span dir="ltr"><<a href="mailto:delawen@gmail.com" target="_blank">delawen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
In my experience, I like Jenkins more than Travis and I think that<br>
with an owned Jenkins we will be able to do much more than with the<br>
Travis service, but I understand that I may be missing something<br>
important here. So it is up to each project to comment if Jenkins<br>
would be a nice solution or not.<br>
<br>
At least for GeoNetwork, it's true that we have Travis linked to our<br>
github (not inside OSGeo organization but on our own), but, at the<br>
same time, what we really use is a Jenkins we have on our own<br>
infrastructure. Every time I try to use Travis, it is unstable and<br>
weird. We can't trust the testing results, for example. But that may<br>
be me, or Java, or GeoNetwork, or who knows, that makes Travis<br>
unfriendly with our project.<br>
<br>
So, going back to the beginning of the thread: Even, will a Jenkins be enough?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, May 1, 2018 at 2:59 PM, Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br>
><br>
>> Hi,<br>
><br>
>> afaik, Jenkins can be configured, that it uses several "cores" - so one Jenkins instance can take advantage of more servers, so  it scales up pretty well.<br>
><br>
>> Actually, in my previous work, we used jenkins quite extensively, developers and even power users were able to setup their own jobs,<br>
>> which were taking fresh code from custom git repo ... it was more or less about writing the shell script, which did all the work<br>
><br>
>> so, if there would be jenkins instance available in osgeo infrastructure, I would prefer it over travis (which pywps is using now)<br>
><br>
><br>
> Yes Jenkins can scale fairly well especially when we throw slaves into the mix.<br>
> I was more thinking about the logistics of delegating administrative rights and configuring slaves in a fashion that power users can configure their own and know what's available on each slave for their tests, cleanup of workspace etc.<br>
> And also the interoperability of the projects.<br>
><br>
> The main reason I like Jenkins is for PostGIS work we need to follow PostgreSQL developments which means we need to test against the head of not yet released PostgreSQL which is something not easy to do with travis.<br>
><br>
> We also need to test against the head of GEOS and GDAL so one of the Jenkins bots we have uses the build output from PostgreSQL, GEOS, GDAL Jenkins jobs and does a matrix job (testing 5 versions of PostgreSQL including dev head) , GEOS head, GDAL head.<br>
><br>
> There is a lot of potential for synergy, but also a bit of "If I need to test GDAL for PostGIS purposes and GDAL needs to test GDAL, but I don't necessarily need to run all the tests GDAL needs to run, where is the balance of power there".  So that's my reasoning for why a single Jenkins might not be sufficient.  It's doable but takes a bit of planning.<br>
><br>
> As far as authentication we can use OSGeo LDAP and designate administrators from each project.  I think having 10 administrators that have full control of the instance from various projects that we all feel comfortable about working together is a workable solution.<br>
><br>
><br>
> Thanks,<br>
> Regina<br>
><br>
><br>
><br>
><br>
><br>
______________________________<wbr>_________________<br>
Board mailing list<br>
<a href="mailto:Board@lists.osgeo.org">Board@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/board" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/board</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><font face="tahoma, sans-serif">Michael Terner</font></div><div><a href="mailto:ternergeo@gmail.com" target="_blank"><font face="tahoma, sans-serif">ternergeo@gmail.com</font></a></div><div><font face="tahoma, sans-serif">(M) 978-631-6602</font></div></div></div></div></div></div></div>
</div>