[Board] Travis-CI & OSGeo

Tue May 1 08:58:50 PDT 2018

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:

   1. Should all OSGeo projects use the same platform (whether it be
   Jenkins, or Travis, or other tooling)?
   2. 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?
   3. 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?

And of course, the overarching question is *what should OSGeo do about it?*

   - Should there be a policy about what tools projects may be *required *to
   use?
   - Should OSGeo setup an open platform, that it supervises and makes
   available (on a voluntary basis) to projects?
   - 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)?

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.

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.

MT

On Tue, May 1, 2018 at 11:05 AM, María Arias de Reyna <delawen at gmail.com>
wrote:

> Hi,
>
> In my experience, I like Jenkins more than Travis and I think that
> with an owned Jenkins we will be able to do much more than with the
> Travis service, but I understand that I may be missing something
> important here. So it is up to each project to comment if Jenkins
> would be a nice solution or not.
>
> At least for GeoNetwork, it's true that we have Travis linked to our
> github (not inside OSGeo organization but on our own), but, at the
> same time, what we really use is a Jenkins we have on our own
> infrastructure. Every time I try to use Travis, it is unstable and
> weird. We can't trust the testing results, for example. But that may
> be me, or Java, or GeoNetwork, or who knows, that makes Travis
> unfriendly with our project.
>
> So, going back to the beginning of the thread: Even, will a Jenkins be
> enough?
>
>
> On Tue, May 1, 2018 at 2:59 PM, Regina Obe <lr at pcorp.us> wrote:
> >
> >> Hi,
> >
> >> 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.
> >
> >> Actually, in my previous work, we used jenkins quite extensively,
> developers and even power users were able to setup their own jobs,
> >> which were taking fresh code from custom git repo ... it was more or
> less about writing the shell script, which did all the work
> >
> >> so, if there would be jenkins instance available in osgeo
> infrastructure, I would prefer it over travis (which pywps is using now)
> >
> >
> > Yes Jenkins can scale fairly well especially when we throw slaves into
> the mix.
> > 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.
> > And also the interoperability of the projects.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> > Thanks,
> > Regina
> >
> >
> >
> >
> >
> _______________________________________________
> Board mailing list
> Board at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/board
>

-- 
Michael Terner
ternergeo at gmail.com
(M) 978-631-6602
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/board/attachments/20180501/953d16ce/attachment.htm>