Travis-CI & OSGeo

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Travis-CI & OSGeo

Even Rouault-2

Hi,

 

Recently projects hosted under the github.com/OSGeo organization (namely GDAL, proj.4 and osgeo4mac), and using Travis-CI for continuous integration builds, have had an issue where the number of 5 concurrent jobs per organization (so for all projects under OSGeo/) was under high stress (some projects could wait for hours before their jobs to be scheduled). We temporarily work arounded that by limiting the number of concurrent builds for GDAL to 4 to leave at least a free slot for the other projects.

 

I contacted Travis-CI support and they gave me a quote to increase the number of concurrent jobs :

10 concurrent jobs: $1925/year

15 concurrent jobs: $3850/year

20 concurrent jobs: $5775/year

(taking into account a 30% discount for non-profit organizations).

 

10 should probably be enough for now.

 

A workaround (cheating) would be for each project to be hosted in its own 'organization', but that would decrease OSGeo github presence (which makes sense to have for a software-focused foundation, right ?), and would be slightly disturbing for users due to URL changes.

 

Thoughts ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Michael Smith
I don’t see any reason why we wouldn’t want to provide this for OSGeo projects. This is part of our mandate, providing infrastructure support for our projects. I’m fully in support of this.

Michael Smith
OSGeo Treasurer


> On Apr 20, 2018, at 10:24 AM, Even Rouault <[hidden email]> wrote:
>
> Hi,
>  
> Recently projects hosted under the github.com/OSGeo organization (namely GDAL, proj.4 and osgeo4mac), and using Travis-CI for continuous integration builds, have had an issue where the number of 5 concurrent jobs per organization (so for all projects under OSGeo/) was under high stress (some projects could wait for hours before their jobs to be scheduled). We temporarily work arounded that by limiting the number of concurrent builds for GDAL to 4 to leave at least a free slot for the other projects.
>  
> I contacted Travis-CI support and they gave me a quote to increase the number of concurrent jobs :
> 10 concurrent jobs: $1925/year
> 15 concurrent jobs: $3850/year
> 20 concurrent jobs: $5775/year
> (taking into account a 30% discount for non-profit organizations).
>  
> 10 should probably be enough for now.
>  
> A workaround (cheating) would be for each project to be hosted in its own 'organization', but that would decrease OSGeo github presence (which makes sense to have for a software-focused foundation, right ?), and would be slightly disturbing for users due to URL changes.
>  
> Thoughts ?
>  
> Even
>  
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Helena Mitasova-7
I am in support of this as well. Helena

On Apr 20, 2018, at 5:46 PM, Michael Smith <[hidden email]> wrote:

I don’t see any reason why we wouldn’t want to provide this for OSGeo projects. This is part of our mandate, providing infrastructure support for our projects. I’m fully in support of this.

Michael Smith
OSGeo Treasurer


On Apr 20, 2018, at 10:24 AM, Even Rouault <[hidden email]> wrote:

Hi,

Recently projects hosted under the github.com/OSGeo organization (namely GDAL, proj.4 and osgeo4mac), and using Travis-CI for continuous integration builds, have had an issue where the number of 5 concurrent jobs per organization (so for all projects under OSGeo/) was under high stress (some projects could wait for hours before their jobs to be scheduled). We temporarily work arounded that by limiting the number of concurrent builds for GDAL to 4 to leave at least a free slot for the other projects.

I contacted Travis-CI support and they gave me a quote to increase the number of concurrent jobs :
10 concurrent jobs: $1925/year
15 concurrent jobs: $3850/year
20 concurrent jobs: $5775/year
(taking into account a 30% discount for non-profit organizations).

10 should probably be enough for now.

A workaround (cheating) would be for each project to be hosted in its own 'organization', but that would decrease OSGeo github presence (which makes sense to have for a software-focused foundation, right ?), and would be slightly disturbing for users due to URL changes.

Thoughts ?

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” 


_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

delawen
If projects need it, I see no reason why not to support it.

On Sat, Apr 21, 2018 at 1:50 AM, Helena Mitasova <[hidden email]> wrote:

> I am in support of this as well. Helena
>
> On Apr 20, 2018, at 5:46 PM, Michael Smith <[hidden email]>
> wrote:
>
> I don’t see any reason why we wouldn’t want to provide this for OSGeo
> projects. This is part of our mandate, providing infrastructure support for
> our projects. I’m fully in support of this.
>
> Michael Smith
> OSGeo Treasurer
>
>
> On Apr 20, 2018, at 10:24 AM, Even Rouault <[hidden email]>
> wrote:
>
> Hi,
>
> Recently projects hosted under the github.com/OSGeo organization (namely
> GDAL, proj.4 and osgeo4mac), and using Travis-CI for continuous integration
> builds, have had an issue where the number of 5 concurrent jobs per
> organization (so for all projects under OSGeo/) was under high stress (some
> projects could wait for hours before their jobs to be scheduled). We
> temporarily work arounded that by limiting the number of concurrent builds
> for GDAL to 4 to leave at least a free slot for the other projects.
>
> I contacted Travis-CI support and they gave me a quote to increase the
> number of concurrent jobs :
> 10 concurrent jobs: $1925/year
> 15 concurrent jobs: $3850/year
> 20 concurrent jobs: $5775/year
> (taking into account a 30% discount for non-profit organizations).
>
> 10 should probably be enough for now.
>
> A workaround (cheating) would be for each project to be hosted in its own
> 'organization', but that would decrease OSGeo github presence (which makes
> sense to have for a software-focused foundation, right ?), and would be
> slightly disturbing for users due to URL changes.
>
> Thoughts ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
>
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
>
>
> Helena Mitasova
> Professor at the Department of Marine,
> Earth, and Atmospheric Sciences
> Associate director and faculty fellow at the Center for Geospatial Analytics
> North Carolina State University
> Raleigh, NC 27695-8208
> [hidden email]
> http://geospatial.ncsu.edu/osgeorel/publications.html
>
> "All electronic mail messages in connection with State business which are
> sent to or received by this account are subject to the NC Public Records Law
> and may be disclosed to third parties.”
>
>
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

R: Travis-CI & OSGeo

Maria Antonia Brovelli
I agree. 
Maria



Inviato dal mio dispositivo Samsung


-------- Messaggio originale --------
Da: María Arias de Reyna <[hidden email]>
Data: 22/04/18 11:49 (GMT+01:00)
A: Helena Mitasova <[hidden email]>
Cc: osgeo-board List <[hidden email]>
Oggetto: Re: [Board] Travis-CI & OSGeo

If projects need it, I see no reason why not to support it.

On Sat, Apr 21, 2018 at 1:50 AM, Helena Mitasova <[hidden email]> wrote:
> I am in support of this as well. Helena
>
> On Apr 20, 2018, at 5:46 PM, Michael Smith <[hidden email]>
> wrote:
>
> I don’t see any reason why we wouldn’t want to provide this for OSGeo
> projects. This is part of our mandate, providing infrastructure support for
> our projects. I’m fully in support of this.
>
> Michael Smith
> OSGeo Treasurer
>
>
> On Apr 20, 2018, at 10:24 AM, Even Rouault <[hidden email]>
> wrote:
>
> Hi,
>
> Recently projects hosted under the github.com/OSGeo organization (namely
> GDAL, proj.4 and osgeo4mac), and using Travis-CI for continuous integration
> builds, have had an issue where the number of 5 concurrent jobs per
> organization (so for all projects under OSGeo/) was under high stress (some
> projects could wait for hours before their jobs to be scheduled). We
> temporarily work arounded that by limiting the number of concurrent builds
> for GDAL to 4 to leave at least a free slot for the other projects.
>
> I contacted Travis-CI support and they gave me a quote to increase the
> number of concurrent jobs :
> 10 concurrent jobs: $1925/year
> 15 concurrent jobs: $3850/year
> 20 concurrent jobs: $5775/year
> (taking into account a 30% discount for non-profit organizations).
>
> 10 should probably be enough for now.
>
> A workaround (cheating) would be for each project to be hosted in its own
> 'organization', but that would decrease OSGeo github presence (which makes
> sense to have for a software-focused foundation, right ?), and would be
> slightly disturbing for users due to URL changes.
>
> Thoughts ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
>
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
>
>
> Helena Mitasova
> Professor at the Department of Marine,
> Earth, and Atmospheric Sciences
> Associate director and faculty fellow at the Center for Geospatial Analytics
> North Carolina State University
> Raleigh, NC 27695-8208
> [hidden email]
> http://geospatial.ncsu.edu/osgeorel/publications.html
>
> "All electronic mail messages in connection with State business which are
> sent to or received by this account are subject to the NC Public Records Law
> and may be disclosed to third parties.”
>
>
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Sandro Santilli-4
In reply to this post by Michael Smith
On Fri, Apr 20, 2018 at 05:46:12PM -0400, Michael Smith wrote:
> I don’t see any reason why we wouldn’t want to provide this for OSGeo projects.

I do: we'd be an OpenSource Software Foundation paying a ClosedSource
Software Company to keep being successful in their business model.

Compare that to giving money to community members willing to provide
build agents to the existing OSGeo build infrastructure (drone.osgeo.org).

See https://wiki.osgeo.org/wiki/Drone

Me and Regina are currently the only ones providing build agents.

Or also, compare that to paying the external service to someone
who puts the service code out there as open source, for example
Drone developer himself ( https://drone.io/pricing/ ) or gitlab
people ( https://about.gitlab.com/pricing/ ).

Or also, to paying sysadmin teams to build these things in-house.

What's been asked here is to pay for what is really just marketing:
showing that "OSGeo has a good presence on GitHub", as if doing so
makes it a _serious_ OpenSource player. This is surrendering to
GitHub marketing stating "where software is built!". Are we paying
to be marketing agents ?


--strk;
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

delawen
On Mon, Apr 23, 2018 at 11:01 AM, Sandro Santilli <[hidden email]> wrote:

> On Fri, Apr 20, 2018 at 05:46:12PM -0400, Michael Smith wrote:
>> I don’t see any reason why we wouldn’t want to provide this for OSGeo projects.
>
> I do: we'd be an OpenSource Software Foundation paying a ClosedSource
> Software Company to keep being successful in their business model.
>
> Compare that to giving money to community members willing to provide
> build agents to the existing OSGeo build infrastructure (drone.osgeo.org).
>
> See https://wiki.osgeo.org/wiki/Drone
>
> Me and Regina are currently the only ones providing build agents.
>
> Or also, compare that to paying the external service to someone
> who puts the service code out there as open source, for example
> Drone developer himself ( https://drone.io/pricing/ ) or gitlab
> people ( https://about.gitlab.com/pricing/ ).
>
> Or also, to paying sysadmin teams to build these things in-house.
>
> What's been asked here is to pay for what is really just marketing:
> showing that "OSGeo has a good presence on GitHub", as if doing so
> makes it a _serious_ OpenSource player. This is surrendering to
> GitHub marketing stating "where software is built!". Are we paying
> to be marketing agents ?
>

You make a good point. Should we reinforce Gitlab then and try to find
a similar service for our projects? How will moving to Gitlab impact
our projects?
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Jeffrey Johnson
How bout we just use what the folks writing the code want to use
rather than being so militant about things?

On Mon, Apr 23, 2018 at 7:13 AM, María Arias de Reyna <[hidden email]> wrote:

> On Mon, Apr 23, 2018 at 11:01 AM, Sandro Santilli <[hidden email]> wrote:
>> On Fri, Apr 20, 2018 at 05:46:12PM -0400, Michael Smith wrote:
>>> I don’t see any reason why we wouldn’t want to provide this for OSGeo projects.
>>
>> I do: we'd be an OpenSource Software Foundation paying a ClosedSource
>> Software Company to keep being successful in their business model.
>>
>> Compare that to giving money to community members willing to provide
>> build agents to the existing OSGeo build infrastructure (drone.osgeo.org).
>>
>> See https://wiki.osgeo.org/wiki/Drone
>>
>> Me and Regina are currently the only ones providing build agents.
>>
>> Or also, compare that to paying the external service to someone
>> who puts the service code out there as open source, for example
>> Drone developer himself ( https://drone.io/pricing/ ) or gitlab
>> people ( https://about.gitlab.com/pricing/ ).
>>
>> Or also, to paying sysadmin teams to build these things in-house.
>>
>> What's been asked here is to pay for what is really just marketing:
>> showing that "OSGeo has a good presence on GitHub", as if doing so
>> makes it a _serious_ OpenSource player. This is surrendering to
>> GitHub marketing stating "where software is built!". Are we paying
>> to be marketing agents ?
>>
>
> You make a good point. Should we reinforce Gitlab then and try to find
> a similar service for our projects? How will moving to Gitlab impact
> our projects?
> _______________________________________________
> Board mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/board
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Tim Sutton-6
Hi



On 23 Apr 2018, at 16:14, Jeffrey Johnson <[hidden email]> wrote:

How bout we just use what the folks writing the code want to use
rather than being so militant about things?

+1…as project leader for GDAL, Even should be given the freedom to manage his project infrastructure in a way that is comfortable for him….I think it is an overreach to require him to retool his entire workflow.

Regards

Tim



On Mon, Apr 23, 2018 at 7:13 AM, María Arias de Reyna <[hidden email]> wrote:
On Mon, Apr 23, 2018 at 11:01 AM, Sandro Santilli <[hidden email]> wrote:
On Fri, Apr 20, 2018 at 05:46:12PM -0400, Michael Smith wrote:
I don’t see any reason why we wouldn’t want to provide this for OSGeo projects.

I do: we'd be an OpenSource Software Foundation paying a ClosedSource
Software Company to keep being successful in their business model.

Compare that to giving money to community members willing to provide
build agents to the existing OSGeo build infrastructure (drone.osgeo.org).

See https://wiki.osgeo.org/wiki/Drone

Me and Regina are currently the only ones providing build agents.

Or also, compare that to paying the external service to someone
who puts the service code out there as open source, for example
Drone developer himself ( https://drone.io/pricing/ ) or gitlab
people ( https://about.gitlab.com/pricing/ ).

Or also, to paying sysadmin teams to build these things in-house.

What's been asked here is to pay for what is really just marketing:
showing that "OSGeo has a good presence on GitHub", as if doing so
makes it a _serious_ OpenSource player. This is surrendering to
GitHub marketing stating "where software is built!". Are we paying
to be marketing agents ?


You make a good point. Should we reinforce Gitlab then and try to find
a similar service for our projects? How will moving to Gitlab impact
our projects?
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
_______________________________________________
Board mailing list
[hidden email]
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Regina Obe

My issue is not that Even shouldn't be given the freedom to manage his project the way he wants.  Of course he should.

 

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.

2)      $5000 or more a year I fair is eventually what you'd need to pay as more projects get added to the GitHub Org

this https://github.com/OSGeo/  the pricier it gets and plus you need to be committed to offer this every year.

-- this extracted from Even's note for those who are not aware

a.  number of 5 concurrent jobs per organization 

 

b.  I contacted Travis-CI support and they gave me a quote to increase the number of concurrent

c.  jobs :

d.  10 concurrent jobs: $1925/year

e.  15 concurrent jobs: $3850/year

f.  20 concurrent jobs: $5775/year

g.  (taking into account a 30% discount for non-profit organizations).

 

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.

 

Like building up our own CI infrastructure that would test more than just Ubuntu.

 

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?

 

 

So my main concern is that this takes away money from other worthy causes and can be easily ameliorated by projects not falling under the Github OSGeo org, and the github/OsGeo org just listing projects and related repos.

 

Might I reiterate I find it self-defeating that we have a GitHub Org and projects like QGIS, GRASS, or PostGIS aren't even represented on it.  The list looks cluttered hard to follow and would be better served with a plain old list.

 

Thanks,

Regina

 

From: Board [mailto:[hidden email]] On Behalf Of Tim Sutton
Sent: Monday, April 23, 2018 10:27 AM
To: Jeffrey Johnson <[hidden email]>
Cc: osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

Hi

 

 



On 23 Apr 2018, at 16:14, Jeffrey Johnson <[hidden email]> wrote:

 

How bout we just use what the folks writing the code want to use
rather than being so militant about things?

 

+1…as project leader for GDAL, Even should be given the freedom to manage his project infrastructure in a way that is comfortable for him….I think it is an overreach to require him to retool his entire workflow.

 

Regards

 

Tim

 




On Mon, Apr 23, 2018 at 7:13 AM, María Arias de Reyna <[hidden email]> wrote:

On Mon, Apr 23, 2018 at 11:01 AM, Sandro Santilli <[hidden email]> wrote:

On Fri, Apr 20, 2018 at 05:46:12PM -0400, Michael Smith wrote:

I don’t see any reason why we wouldn’t want to provide this for OSGeo projects.


I do: we'd be an OpenSource Software Foundation paying a ClosedSource
Software Company to keep being successful in their business model.

Compare that to giving money to community members willing to provide
build agents to the existing OSGeo build infrastructure (drone.osgeo.org).

See https://wiki.osgeo.org/wiki/Drone

Me and Regina are currently the only ones providing build agents.

Or also, compare that to paying the external service to someone
who puts the service code out there as open source, for example
Drone developer himself ( https://drone.io/pricing/ ) or gitlab
people ( https://about.gitlab.com/pricing/ ).

Or also, to paying sysadmin teams to build these things in-house.

What's been asked here is to pay for what is really just marketing:
showing that "OSGeo has a good presence on GitHub", as if doing so
makes it a _serious_ OpenSource player. This is surrendering to
GitHub marketing stating "where software is built!". Are we paying
to be marketing agents ?


You make a good point. Should we reinforce Gitlab then and try to find
a similar service for our projects? How will moving to Gitlab impact
our projects?
_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

_______________________________________________
Board mailing list
[hidden email]
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Howard Butler-3

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Jeffrey Johnson
As the OSGeo representative for a project (GeoNode) that simply
refuses to use SAC resources because they are really not suitable or
reliable for our development community, and as a Principal at a
company organized around supporting GeoNode installs who gladly pays
for our own resources rather than invest time and effort to try to
work with volunteers whose ability to deliver may be hit or miss, this
all rings quite true. Having gone through the process of incubation, I
think the project is left wondering what we actually get from OSGeo
other than a stamp of approval, which so far doesn't seem to have
concretely benefited the project that much.

Not exactly sure what the solution is, but with gdal/ogr being one of
the most core projects to all that all of us do, it seems we, as a
community should be going out of our way to make sure we give them
what they need to continue to develop and maintain this project as
efficiently as possible and not let zealotry or militance about not
using commercial projects get in the way.

On Mon, Apr 23, 2018 at 10:04 AM, Howard Butler <[hidden email]> wrote:

>
> On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Regina Obe
In reply to this post by Howard Butler-3

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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <[hidden email]>
Cc: Tim Sutton <[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Vicky Vergara-2
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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <[hidden email]>
Cc: Tim Sutton <[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board



--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Even Rouault-2
In reply to this post by Sandro Santilli-4

On lundi 23 avril 2018 11:01:34 CEST Sandro Santilli wrote:

> On Fri, Apr 20, 2018 at 05:46:12PM -0400, Michael Smith wrote:

> > I don’t see any reason why we wouldn’t want to provide this for OSGeo

> > projects.

> I do: we'd be an OpenSource Software Foundation paying a ClosedSource

> Software Company to keep being successful in their business model.

 

The aim here would be that *OSGeo projects* are successful in their developments

needs. The fact that a commercial company makes profit from that is a side effect,

not the primary goal.

 

Interestingly the Apache foundation has 1538 repositories listed under

https://github.com/apache

I've just found this interesting post:

https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci

where they mention they have subscribed for 30 concurrent jobs.

 

Given the current use of github.com/OSGeo, 10 would be enough for now IMHO.

 

>

> Compare that to giving money to community members willing to provide

> build agents to the existing OSGeo build infrastructure (drone.osgeo.org).

 

According to the specs displayed at

https://docs.travis-ci.com/user/reference/overview/#Virtualization-environments

the Ubuntu Precise workers must probably run on a n1-standard-2 GCE machine

According to https://cloud.google.com/compute/pricing , the monthly price for such

a pre-emptive VM is $14.60

If you have '10 concurrent jobs' it means that you can have in theory a need for

10 such VMs. So 10 VMs for a year would be 14.60 * 12 * 10 = $1752 / year

which is not so far from the $1925/year of their quote.

 

Of course in practice the CI company must have some good statistics on the average

load actually used by a project, and thus it knows it does not need to rent as

many VMs, and still have some money to pay for their employees to monitor

this complex beast.

 

https://drone.io/pricing/ is $129 * 12 = $1548 / year for 2 concurrent builds, so

for 10, naively that would be $7740

 

Owing your own server(s) is now a luxury, which is rather costly and unefficient,

given that they are either under-loaded or over-loaded, but rarely utilized at their

full capacity.

 

I also hear your argument that there are solutions like Drone or GitLab that use

open source software, which is great. But at some point you need to make that

software run on servers, that you must buy or rent, and that you must monitor, maintain, etc.

 

Regarding Regina's

"First of all if this is something GDAL needs and Proj needs, then it should

come out of GDAL's/ Proj's budget "

This is a good point, and a reasonable solution. OSGeo would need to know which

projects are hosted under github.com/OSGeo and use Travis-CI to be able to select

the appropriate number of workers (which is a bit tricky since the actual use of the

CI infrastructure depends very much on the project activity)

 

"If you each had your own project group on github you'd each have 5 workers

end of story."

1) I wasn't aware of the per-org 5 job limitation until very recently

2) https://github.com/gdal /proj /proj4 are already occupied.

 

"You wouldn't even need to waste funding on this."

 

That's the kind of workaround/cheating which causes others to pay for resources you

use. And thus increase their bills... and/or may decrease the quality of the free tier.

 

I'm not against considering other CI solutions that integrate will with github such as

https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

that Sandro mentionned to me, although I can't find information about what the

limitations are regarding the number of concurrent jobs, and if there would be

per project or organization.

And there would be "some" labor cost to migrate the existing 12 Travis-CI

configurations currently used by GDAL to that

( https://travis-ci.org/OSGeo/gdal/builds/370031450 )

 

By the way, who has admin rights on

https://gitlab.com/osgeo

and grant me appropriate rights so I can have a try at setting up the

gitlab-ci-for-github thing for GDAL ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Tim Sutton-6
In reply to this post by Vicky Vergara-2
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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <[hidden email]>
Cc: Tim Sutton <[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board



--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@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
[hidden email]
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Regina Obe

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:[hidden email]]
Sent: Monday, April 23, 2018 5:13 PM
To: Vicky Vergara <[hidden email]>
Cc: Regina Obe <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <[hidden email]>
Cc: Tim Sutton <[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board




--

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany
 
Vicky Vergara
Operations Research
 
eMail: vicky@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
[hidden email]
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Jeffrey Johnson
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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 5:13 PM
To: Vicky Vergara <[hidden email]>
Cc: Regina Obe <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <[hidden email]>
Cc: Tim Sutton <[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board




--

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany
 
Vicky Vergara
Operations Research
 
eMail: vicky@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
[hidden email]
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Regina Obe

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

 

That's kind of the thing I wanted to push for thus my reason for joining SAC.  We have a couple of things we have in pipe – which we will do once we get new hardware and also using infrastructure Funtoo org was offered us. I'd use PostGIS as a proof of concept though it needs some cleanup.

 

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

 

True admittedly there hasn't been evidence which has concerned me too, thus I wanted to be part of the solution and make evidence.

There is a certain self-defeating helplessness in projects that bothers me.  It's always a SAC does nothing for me. OSGeo does nothing for me.

In a sense it's self-defeating because if you expect nothing you will get nothing and you will frustrate those of us trying with (well they certainly don't care for my input).

 

On PostGIS side there is a lot of sentiment like that too – but I think hey I depend on OSGeo for a place to put my downloads, for my mailing lists, and at least currently

 

Sure old ways like Travis are useful and good for the present, but I worry about too much reliance of a single company especially one that has to answer to investors who could care less about open source.  The bigness of them to me is an artificial thing, and I'd hate that to stifle smaller players with great ideas or Uni kids wanting to explore administration and testing and thinking (why bother cause GitHub/Amazon etc. has already solved the world's problems)

 

 

To Even's point:

 

 

> That's the kind of workaround/cheating which causes others to pay for resources you

> use. And thus increase their bills... and/or may decrease the quality of the free tier.

There are several schools of thought to this. Mine are the following, which is why I feel little guilt

 

a)  In my mind, my use is advertising they can add to their statistics.  Private companies that use my work should be footing the bill and we/they should do more to extract money from these private companies.

 

b)  These companies (not speaking necessarily of Travis) are venture funded, so their progression is not organic and could be stifling growth of smaller companies who can provide similar services who are growing organically.  I'd rather see many more Travis's, AppVeyors, and Github than one big one for the same reason I appreciate having thousands of cloud hosters to choose from.

 

 

> I also hear your argument that there are solutions like Drone or GitLab that use

> open source software, which is great. But at some point you need to make that

> software run on servers, that you must buy or rent, and that you must monitor, maintain, etc.

 

The value I see in using an open solution is not just that I can run it on my own servers and tweak it for my own needs, also it's that it is more likely to lead to me having more choices of providers I can rely on that are easy to move to. Granted this starts getting messy with the plethora of OSL licenses.

 

Take my favorite example of PostgreSQL – there are a ton of PostgreSQL service providers (big and small players) now and all the big ones Amazon, Microsoft Azure, Google now offer it as a service.  Most are offering PostGIS at this point too cause they can since it too is open source.  This would not be possible if PostgreSQL is closed.

 

So yah each has their own tweaks, but I know hey if Amazon pisses me off, Microsoft has a close enough offering I can move to.

 

Thanks,

Regina

 

 

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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 5:13 PM
To: Vicky Vergara <
[hidden email]>
Cc: Regina Obe <
[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <
[hidden email]>
Cc: Tim Sutton <
[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board




--

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany
 
Vicky Vergara
Operations Research
 
eMail: vicky@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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

 

 


cid:image001.jpg@01D3DB65.DAD442C0

 

 

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board


_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board
Reply | Threaded
Open this post in threaded view
|

Re: Travis-CI & OSGeo

Jachym Cepicky
Hi,

sorry jumping so late into this discussion. 

For PyWPS, we are using travis-ci infrastructure.

But I can imagine, that having osgeo.org/jenkins instance at hand, we would move straight way. I had chance to use jenkins in the past and it works nice. And it can be used for automatic build of packages etc .. did you consider this? I hope, I have not missed someones mail to this topic already

Jachym

út 24. 4. 2018 v 7:09 odesílatel Regina Obe <[hidden email]> napsal:

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

 

That's kind of the thing I wanted to push for thus my reason for joining SAC.  We have a couple of things we have in pipe – which we will do once we get new hardware and also using infrastructure Funtoo org was offered us. I'd use PostGIS as a proof of concept though it needs some cleanup.

 

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

 

True admittedly there hasn't been evidence which has concerned me too, thus I wanted to be part of the solution and make evidence.

There is a certain self-defeating helplessness in projects that bothers me.  It's always a SAC does nothing for me. OSGeo does nothing for me.

In a sense it's self-defeating because if you expect nothing you will get nothing and you will frustrate those of us trying with (well they certainly don't care for my input).

 

On PostGIS side there is a lot of sentiment like that too – but I think hey I depend on OSGeo for a place to put my downloads, for my mailing lists, and at least currently

 

Sure old ways like Travis are useful and good for the present, but I worry about too much reliance of a single company especially one that has to answer to investors who could care less about open source.  The bigness of them to me is an artificial thing, and I'd hate that to stifle smaller players with great ideas or Uni kids wanting to explore administration and testing and thinking (why bother cause GitHub/Amazon etc. has already solved the world's problems)

 

 

To Even's point:

 

 

> That's the kind of workaround/cheating which causes others to pay for resources you

> use. And thus increase their bills... and/or may decrease the quality of the free tier.

There are several schools of thought to this. Mine are the following, which is why I feel little guilt

 

a)  In my mind, my use is advertising they can add to their statistics.  Private companies that use my work should be footing the bill and we/they should do more to extract money from these private companies.

 

b)  These companies (not speaking necessarily of Travis) are venture funded, so their progression is not organic and could be stifling growth of smaller companies who can provide similar services who are growing organically.  I'd rather see many more Travis's, AppVeyors, and Github than one big one for the same reason I appreciate having thousands of cloud hosters to choose from.

 

 

> I also hear your argument that there are solutions like Drone or GitLab that use

> open source software, which is great. But at some point you need to make that

> software run on servers, that you must buy or rent, and that you must monitor, maintain, etc.

 

The value I see in using an open solution is not just that I can run it on my own servers and tweak it for my own needs, also it's that it is more likely to lead to me having more choices of providers I can rely on that are easy to move to. Granted this starts getting messy with the plethora of OSL licenses.

 

Take my favorite example of PostgreSQL – there are a ton of PostgreSQL service providers (big and small players) now and all the big ones Amazon, Microsoft Azure, Google now offer it as a service.  Most are offering PostGIS at this point too cause they can since it too is open source.  This would not be possible if PostgreSQL is closed.

 

So yah each has their own tweaks, but I know hey if Amazon pisses me off, Microsoft has a close enough offering I can move to.

 

Thanks,

Regina

 

 

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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 5:13 PM
To: Vicky Vergara <
[hidden email]>
Cc: Regina Obe <
[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>


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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
Sent: Monday, April 23, 2018 1:04 PM
To: Regina Obe <
[hidden email]>
Cc: Tim Sutton <
[hidden email]>; Jeffrey Johnson <[hidden email]>; osgeo-board List <[hidden email]>; Sandro Santilli <[hidden email]>
Subject: Re: [Board] Travis-CI & OSGeo

 

 

On Apr 23, 2018, at 9:50 AM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board




--

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany
 
Vicky Vergara
Operations Research
 
eMail: vicky@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
[hidden email]
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board


--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp

_______________________________________________
Board mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/board

image001.jpg (8K) Download Attachment
image001.jpg (8K) Download Attachment
123