Hello Thomas, 2012/4/10 Thomas Petazzoni <[email protected]>: > 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
