[OSGeo-Discuss] OSGeo guidelines for code hosting ?

Jody Garnett jody.garnett at gmail.com
Sun Oct 18 15:04:06 PDT 2015

That repo-criteria articles is a great read - thanks!

One key advantage OSGeo has as a foundation is we are not "picky" about
where projects work from. This allows our projects to be more responsive
then similar foundations such as Apache and Eclipse. It should be noted
that these organizations require the use of their own for facilities for
reasons other than hosting (Apache wants to have a "kill switch" on
downloads and source code if any legal challenge is issued to mitigate any
damages payed out, Eclipse Foundation quite sensibly wants to have a copy
of the code incase the external forge goes down so the team does not lose
their work).

As for OSGeo we are pretty relaxed - I think the only thing we would be
actively worried about is a project hosted by a corporate CSV or similar
(since we like our projects to be vendor neutral). Before OSGeo was founded
we suffered when Refractions SVN was corrupted.

Personally I would like to ensure "we" have a copy of the code incase a
projects infrastructure goes down (example CodeHaus, Source Forge). Right
now we depend on individual committers to have a copy.

I want to be cautious of asking the board to make decisions affecting the
system admin committee.  I would prefer projects such as PostGIS negotiate
with the SAC directly (as they are in a much better position to determine
requirements/solution). The Board can be told of the plan of course, but we
need to trust our subcommittees and respect our volunteers (Indeed Regina
Obe's email backs up my feelings on this matter).

There is a balance between OSGeo branding (we could purchase GitHub
Enterprise and hook into our LDAP for example) and developer outreach
(allowing developers to work with the github account they already have
setup). I think we should keep an eye on it as GitHub popularity will
change over time just like Source Forge before it. At the time of writing I
would recommend all projects at least have a mirror on GitHub as an
outreach activity.

Aside: Please make sure your GitHub repository has a CONTRIBUTING.md
<https://github.com/blog/1184-contributing-guidelines> file or similar if
you are accepting pull requests from the big bad internet.

Jody Garnett

On 18 October 2015 at 00:07, Andreas Hocevar <andreas.hocevar at gmail.com>

> Very well said Andrea, and I can back this up with very similar
> experiences from when the OpenLayers project moved to Github.
> That said, if OSGeo considers setting up a Git infrastructure, please keep
> an alternative in mind: pay for an OSGeo Github account for projects that
> want to use Git. Will burn some money, but won't burn out volunteers who
> have to keep OSGeo's own infrastructure up and running. See
> https://github.com/locationtech as an example.
> Andreas.
> On 18 Oct 2015, at 08:41, Andrea Aime <andrea.aime at geo-solutions.it>
> wrote:
> Hi,
> just wanted to chime in saying that if OSGeo starts setting said
> guidelines,
> it should also have some benefits comparison so that projects can
> see what they might not get by avoiding Github.
> In particular, looking at GeoServer experience from the switch, it's rather
> evident we got more people contributing right the moment we did the
> switch, here is the contributors per month diagram, the red line
> is the date we switched from svn to GitHub:
> <Selezione_095.png>
> Most of this is due to two factors:
> - availability of pull requests (which I believe you can get with other
> tools too)
> - critical mass on the platform (which arguably you will not get an a
> OsGeo hosting)
> There is however a downside of that, most of these contributions are "one
> time gigs",
> people help addressing the particular pitfall concerning them and then
> they move on:
> github did not change the number of core developers, it just increased a
> lot the
> number of other contributors.
> There is another benefit of moving to Github, which is build checks on
> pull requests,
> we now have Travis (Linux, OSX) building all pull requests and running the
> test suite against
> them, so we instantly know if the change breaks tests or not, and we
> planning on adding
> test coverage checks (Coveralls, already used by OpenLayers for example)
> and Windows builds
> (already used by MapServer for example).
> This kind of automation is also rather beneficial to filter our bad
> contributions... which is
> the dark side of lower contribution barrier, core devs have to spend quite
> some time evaluating
> pull requests... but ending up with a long queue of them gives a bad
> impression about the project
> openness. So yeah, another bit to consider I guess, is the project ready
> to take on them?
> So.... I'm not saying "everybody move to github" but I believe the above
> should be
> part of the many considerations made when evaluating a move to a different
> version control.
> Cheers
> Andrea
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
> Ing. Andrea Aime
> @geowolf
> Technical Lead
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
> -------------------------------------------------------
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20151018/6b062e9d/attachment.html>

More information about the Discuss mailing list