[Osmf-talk] Core OpenStreetMap software development and support

[Дмитрий Киселев]

Hi OSMF,

I'm 100% agree with Darafei, Code of Conduct regulates how the internal
communication inside OSMF should work,
it's not the primary goal of OSMF to have or not to have COC.

If diffs are broken, or planet dump is corrupted (what sometimes happens)
core software stack is what you are care of.


2017-12-04 6:47 GMT-04:00 Darafei "Komяpa" Praliaskouski <me at komzpa.net>:

> Hi,
>
> I'd like to flag an issue with our core software development process.
>
> openstreetmap.org is a complex system of many different servers being
> currently maintained by operations working group. Server hardware are being
> regularly taken care of, even though OWG consists of volunteers.
>
> If we look at https://github.com/openstreetmap we can see that project
> consists of many parts from software point of view. Some of them are
> maintained (notably JOSM, iD and openstreetmap-carto), but that's not the
> case for the rest. Let's have a look at what happened since June:
>
> openstreetmap-website, the rails application powering most of osm.org -
>  81 commits by Tom Hughes, mostly being security and policy tweaks;
>  19 commits by Bryan Housel, mostly being iD editor version bump;
>  18 commits by Andy Allan, mostly being refactorings.
> 277 open issues, 34 non-merged pull requests.
> https://github.com/openstreetmap/openstreetmap-
> website/graphs/contributors?from=2017-06-01&to=2017-12-04&type=c
>
> cgimap, c++ application powering /map call -
> no commits.
> https://github.com/openstreetmap/cgimap/graphs/
> contributors?from=2017-06-01&to=2017-12-04&type=c
>
> Both projects have major performance issues known for a year, with a
> prototype fix:
> https://github.com/Komzpa/fastmap. There is also an issue with
> replication diffs being implemented on top of unsuitable postgres mechanism
> that may cause data loss in diffs and resurrection of old data:
> https://github.com/openstreetmap/operations/issues/154
>
> mod_tile/renderd, c toolchain powering our tile servers:
> no commits. 77 issues raised. 19 pull requests waiting to be merged.
> has an issue of under-utilizing rendering server capacity.
> There is big comment on what needs to be improved by apmon:
> https://github.com/openstreetmap/mod_tile/pull/152#issuecomment-348805403
>
> osm2pgsql, c(++) application powering our tile servers:
> 10 commits. 84 issues. 8 pull requests open.
> https://github.com/openstreetmap/osm2pgsql/graphs/contributors?from=2017-
> 06-01&to=2017-12-04&type=c
>
> Lack of resources to fix core issues is sometimes leading to workarounds
> that prevent growth:
>
>  - issues with scalability of rendering cluster led to bans and blocks of
> different web sites using openstreetmap's tiles;
>
>  - issue with API database scalability was worked around as "limit
> changeset size to less objects" instead of fixing the underlying API
> slowness and timing out issue. Discussions just blocked after merge:
> https://github.com/openstreetmap/openstreetmap-website/pull/1259
>
> OSMF was created as an organization to support the OpenStreetMap project
> and not shape the community. I think that this is precisely where OSM needs
> support and ask OSMF board to provide a way for us all to get out of the
> situation.
>
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>
>


-- 
Best regards,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20171204/f1dc4a75/attachment.html>