[Board] Travis-CI & OSGeo

Regina Obe lr at pcorp.us
Mon Apr 23 10:36:28 PDT 2018


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

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. :)

 

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

 

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

 

 





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/board/attachments/20180423/ac5011b6/attachment.htm>


More information about the Board mailing list