Re: [Maposmatic-dev] Outstanding points before releasing MapOSMatic

[David MENTRE]

Hello Thomas,

2012/4/10 Thomas Petazzoni <address@hidden>:
> Here are some remaining issues, and I have the unfortunate feeling that
> the list is growing rather than reducing, so I'm fearing that we will
> (again) not release MapOSMatic soon... or at least not as soon as we
> wanted to do it.

I think you are overly pessimistic. Most of below issues are
non-blocking or at least we have work around, so we can hopefully
release in time.

>  * Many translations are still out of date, though I will not consider
>   this as a blocker for the release. See attached file for the current
>   status of the translations.

Yes, this is non blocking.

>  * Gaël patches on the scale problem has also changed significantly the
>   scale of booklets.

Non blocking for me. Of course we should fix that but we should not
target a perfect release.


>  * Renderings of Paris in booklet mode is timeout-ing on the main
>   server, taking more than 20 minutes to complete. We could solve this
>   by further increasing the accepted maximum rendering duration up to
>   30 or 40 minutes.

Yes, let's increase rendering time to 30 min or 40 min. If Paris does
not fit in that time, then yes we have an issue.

>  * The automated updates of the planet database have stopped, and we
>   don't know how to start them again. We have hit the period during
>   which the OSM database was read-only and things seem to have changed
>   with regard to the upgrade process. So our replication lag is
>   growing again, and we don't know how to fix it,

This one is a real issue I think.

>  * The MapQuest stylesheets on the server are broken.

I think this is non blocking. We can even deactivate this style sheet,
and reactivate it once it is fixed.


>  * We have a regular Out-of-memory issue on the rendering server, but
>   unfortunately, the kernel seems to be unable to kill the
>   memory-hungry process and simply crashes the VM. This is the reason
>   for the last 2/3 outages of the maposmatic.org site. A potential
>   solution would be to start the rendering daemon with a fixed ulimit
>   so that the process gets killed when it consumes too much memory.

This is also a blocking issue. Hopefully the memory issue is related
to our rendering daemon. Let's try the ulimit approach.

Best regards,
david