[Board] Travis-CI & OSGeo

Mon Apr 23 16:28:48 PDT 2018

Fwiw, Our customers that are developing/running many projects in their own
private clouds and networks are heavy users of gitlab and Jenkins among
other tools. In many cases the code is developed primarily on github with
Travis running tests (and often other tools in the build) and then mirrored
onto a private gitlab and Jenkins setup where further quality assurance,
release and deploy steps are run. I would be in favor of this kind of
integrated setup for OSGeo with both sides of the equation represented, but
haven’t seen evidence that we are capable of organizing that, setting cross
project standards and coming up with a more coherent plan that represents
the organization clearly and professionally. Again as a project lead I’m
not quite sure what it is we got for going through incubation other than
more eyeballs perhaps.

On Mon, Apr 23, 2018 at 14:50 Regina Obe <lr at pcorp.us> wrote:

> Tim,
>
>
>
> Well put and sorry for letting my sanctimony get in the way of my
> helpfulness.
>
> Overall I think it was a good discussion and brought out some useful
> approaches that all projects can benefit from.
>
> It's good to see so much interest on gitlab (as aired here and also on
> postgis irc).
>
>
>
> Thanks,
>
> Regina
>
>
>
>
>
> *From:* Tim Sutton [mailto:tim at kartoza.com]
> *Sent:* Monday, April 23, 2018 5:13 PM
> *To:* Vicky Vergara <vicky at georepublic.de>
> *Cc:* Regina Obe <lr at pcorp.us>; osgeo-board List <board at lists.osgeo.org>;
> Sandro Santilli <strk at kbt.io>
>
>
> *Subject:* Re: [Board] Travis-CI & OSGeo
>
>
>
> Hi Regina and friends
>
>
>
> Regarding using a discrete GitHub org, I agree this is good advice for
> Even. GIS.ORG has its own org in GitHub and we also benefit from
> exclusive use of the 5 travis jobs, autonomy over how we manage our org,
> and other good things.. Even: I know that Matthias Kuhn also squeezed a lot
> of mileage out of travis for QGIS, so you might want to chat to him and ask
> for any tips and tricks he might have to share.
>
>
>
> QGIS, by the way, is going to move to GitLab for a complex of reasons.
> Such moves are highly disruptive and should not be recommended lightly to a
> project. Especially in Even’s case who, if you follow hist activities, has
> only just moved GDAL over to GitHub and who is, I am sure, 100% not
> interested in doing the whole thing over again before another 10 years have
> passed :-P
>
>
>
> Reflecting on the more ‘flaming arrow' parts of the discussion, I do think
>  it is good to take on board the general sentiment of the thread: if people
> write for help we should try to focus on solving their problems, not derail
> the conversation by airing views on their ‘bad’ technology choices. Even
> for one is, I am sure, well aware of what open source is, the benefits to
> humanity it offers etc. …… and also the utility he can get from a well run,
> stable and richly functional service like GitHub that can help him share
> his great work to the world.
>
>
>
> Regards
>
>
>
> Tim
>
>
>
>
>
> On 23 Apr 2018, at 20:52, Vicky Vergara <vicky at georepublic.de> wrote:
>
>
>
> Hi all,
>
> I agree with Regina,
>
> In my own experience with pgRouting as Community project:
>
> We have pgRouting as a "GitHub organization" and have.
>
>
> it has 3 sub-projects repositories:
>
> pgrouting  -- very active using travis  (notice the lowercase r, so
> pgRouting its not only the thing used in postgreSQL)
>
> pgRoutinglayers -- not using travis
>
> osm2pgrouting -- somehow active using travis
>
> in addition to that we also have:
>
> Website
>
> Workshop -- somehow active using travis
>
> And a series of forks that we use to make contirbutions to other projects
> for example:
> osgeo
>
> Forked from OSGeo/osgeo
>
>
>
> Also we have stalled ideas in other repositories under pgRouting
>
> In total we have 15 repositories
>
> And we can manage with the 5 concurrent jobs
>
> A testing build of pgRouting has 6 jobs that 5 take around 8 to 9 minutes
> and 1 takes less than 3 minutes.
>
> We are making use of being open and using the "free" advantages of github.
>
> And we are not consuming OSGeo valuable resources that can be used in
> other key things.
>
> VIcky
>
>
>
>
>
>
>
>
>
> On Mon, Apr 23, 2018 at 12:36 PM, Regina Obe <lr at pcorp.us> wrote:
>
> Apology for the flaming arrows.  Howard and I love to throw arrows at each
> other.
>
>
>
> Oh where do I start here?
>
>
>
> From an idealist standpoint.  Yes I am crazy enough to think I can make a
> difference and provide something complementary to travis and appveyor.
>
> I do not think they satisfy all needs without going thru some crazy hoops.
>
> As strk mention gitlab is an alternative , though you may not be
> interested in it.
>
>
>
> From a pragmatic standpoint I think "why are we sanctioning spending
> $5000/yr in the name of OSGeo projects on something that people need to be
> under OSGeo github to take advantage of?".
>
>
>
> First of all if this is something GDAL needs and Proj needs, then it
> should come out of GDAL's/ Proj's budget J
>
> So if Even were to say hay GDAL needs $5000/year for this thing, then by
> all means yes we should give it to him and he should put it in his budget.
>
> GDAL deserves that much per year.  Same with Proj.
>
>
>
> But don't make it a  "OSGeo Projects" need this.
>
> I don't need it I don't want it, and I don't see the point of having an
> OSGeo GitHub org that doesn't even reflect all our projects.
>
>
>
> It still stands that this would be a non-issue if you guys didn't create a
> skeletal OSGeo github group where GDAL and proj.4 are the projects eating
> up all the workers.
>
> If you each had your own project group on github you'd each have 5 workers
> end of story.  You wouldn't even need to waste funding on this. J
>
>
>
> You'd also have more room to breathe as you can create many github
> subprojects as QGIS has done and not crowd everyone else out J
>
>
>
> https://github.com/QGIS
>
>
>
> When people go to github to look for GDAL or proj.4 they could care less
> you are an OSGeo project.  They already know YOU and are looking for YOU.
>
>
>
> If someone goes to https://github.com/OSGEO they think - so these are all
> the projects OSGeo has – NOOOO.  It's NEGATIVE advertising.
>
>
>
> So both my idealistic and pragmatic sides are disappointed by this
> movement to grow the github OSGeo Org for no benefit.
>
>
>
>
>
> Thanks,
>
> Regina
>
>
>
>
>
>
>
> *From:* Howard Butler [mailto:howard at hobu.co]
> *Sent:* Monday, April 23, 2018 1:04 PM
> *To:* Regina Obe <lr at pcorp.us>
> *Cc:* Tim Sutton <tim at kartoza.com>; Jeffrey Johnson <ortelius at gmail.com>;
> osgeo-board List <board at lists.osgeo.org>; Sandro Santilli <strk at kbt.io>
> *Subject:* Re: [Board] Travis-CI & OSGeo
>
>
>
>
>
> On Apr 23, 2018, at 9:50 AM, Regina Obe <lr at pcorp.us> wrote:
>
>
>
> My issue is not that Even shouldn't be given the freedom to manage his
> project the way he wants.  Of course he should.
>
>
>
> Yes it is. You're arguing that you can spend $5000 on something more
> worthy than supporting GDAL with the project infrastructure it wants to
> maintain under OSGeo's umbrella.
>
>
>
> The point is that
>
>
>
> 1)      He is limited because he is under the OSGEO Project
> infrastructure on Github.  If he were on his own project space, like
> PostGIS or QGIS (or Geos used to be), he wouldn't be limited by the 5
> worker limit. I fail to see what benefit this Org is doing us when several
> of aour key projects aren't even on it (e.g. QGIS, GRASS, PostGIS) and even
> if they are what is the point, people should be lured to the osgeo website,
> not github.
>
>
>
> This is a really good point. Why should projects that are to be on their
> own for infrastructure and support bother with putting anything under an
> OSGeo umbrella at all?
>
>
>
> Or in a less snarky tone, OSGeo needs to decide if supporting projects
> with infrastructure is part of its mission. Member projects have no
> budgetary power to put resources into infrastructure capabilities that work
> for them of their choice, and there's a SAC beast that must be fed with
> money and take on new projects to continue to have relevance. Many projects
> actively avoid SAC and OSGeo resources because it is lesser quality
> infrastructure. It is lesser quality infrastructure because it is really
> damn hard to be all things to everybody. Add the fact that SAC is almost
> entirely unrecognized volunteer effort, and it is very difficult to succeed
> long term with any kind of staying power.
>
>
>
> GitHub, Travis, and AppVeyor are products. They cost money. They are
> specialized tools. They work really well. They have organizations behind
> them. They didn't exist in 2006 when OSGeo was formed, so we started down
> the path of building our own. If we started in 2018, I'm unconvinced we
> would have built our own.
>
>
>
> 3)      I think with $5000, that's almost the size of the osgeo budget
> for hardware.  I think of all the good we could do with $5000/yr and
> something that could help all projects not just things hosted on GitHub.
>
>
>
> Infrastructure is *so* much more than a piece of hardware in a subsidized
> data center that graciously hosts us.
>
>
>
> Like building up our own CI infrastructure that would test more than just
> Ubuntu.
>
>
>
> You can use Docker with Travis to test whatever flavor you want.
>
>
>
> And what about AppVeryor.  How much are you going to have to pay for
> that?  Is it under the same core limitations or will you have to shell out
> an additional $5000/yr for that?
>
>
>
> Yes, I would hope so. Sandro is very vocal about his disdain for Windows,
> so I'm sure he will complain, but you've made good business supporting
> windows prisoners, so maybe you won't.
>
>
>
> Is OSGeo a software foundation that supports projects that make software,
> or is it an advocacy organization for users looking to get leverage off of
> free and open source software? The balance has been wildly tipped toward
> the latter the past 5 years... The board needs to clearly signal OSGeo's
> relationship to its member projects in this regard. I hope the board can
> ignore the flaming arrows Regina and I are shooting at each other in a
> battle that will never end and make a decision about OSGeo's relationship
> to its member projects and their infrastructure. If the relationship is
> "you must use SAC stuff", then the board needs to dump significantly more
> resources into burnishing that infrastructure to an outcome that might
> still be unsatisfactory. If the relationship is "use whatever you want and
> pay for it yourself", projects with the wherewithal to do so are going to
> do it outside of an organization that frankly isn't providing them with
> anything. If the relationship is "incubated projects get XXX dollars of
> infrastructure funding to spend on tools of its choosing", maybe this acts
> as both an incentive to incubate and a ring to reach for.
>
>
>
> What we have now, where the answer is "volunteer your volunteers' time to
> build infrastructure within SAC" is not the solution.
>
>
>
> Howard
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Board mailing list
> Board at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/board
>
>
>
>
> --
>
> Georepublic UG (haftungsbeschränkt)
>
> Salzmannstraße 44,
>
> 81739 München, Germany
>
>
>
> Vicky Vergara
>
> Operations Research
>
>
>
> eMail: vicky at georepublic.de
>
> Web: https://georepublic.info
>
>
>
> Tel: +49 (089) 4161 7698-1
>
> Fax: +49 (089) 4161 7698-9
>
>
>
> Commercial register: Amtsgericht München, HRB 181428
>
> CEO: Daniel Kastl
>
>
>
> _______________________________________________
> Board mailing list
> Board at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/board
>
>
>
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
>
>
> *Co-founder:* Kartoza
>
> *Project chair:* QGIS.org
>
>
>
> Visit http://kartoza.com to find out about open source:
>
>
>
> Desktop GIS programming services
>
> Geospatial web development
>
> GIS Training
>
> Consulting Services
>
>
>
> *Skype*: timlinux
>
> *IRC:* timlinux on #qgis at freenode.net
>
>
> _______________________________________________
> Board mailing list
> Board at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/board
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/board/attachments/20180423/4c26099d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/board/attachments/20180423/4c26099d/attachment.jpg>