[OSM-dev] Release openstreetmap-carto v2.25.0
info at matthijsmelissen.nl
Thu Dec 11 22:59:40 UTC 2014
On 11 December 2014 at 15:16, Andy Allan <gravitystorm at gmail.com> wrote:
> If anyone has any advice, I'm all ears.
I'm happy Christoph started this discussion. I agree with most things
that have already been said.
I think the main problem is that the time from design to deployment of
changes is currently too long, especially for changes that correct
bugs introduced earlier.
Andy mentions that he thinks that the pull requests he has merged are
not the most important ones. Of course, everyone considers different
things important. Some of the things we did I think were quite
important, such as shop rendering, mid-zoom path rendering, and the
landcover labels. But I think the main result so far is that the code
is much more consistent (although not perhaps not always easier to
understand), in particular related to roads and labels. Also, the
issues Andy referred to as important are mainly graphical design
issues, which I'm not very good at. It might be an idea to attract
some people who are good at design.
Furthermore, we cannot expect large changes from new developers, so I
think it is entirely reasonable for new developers to make pull
requests that seem trivial and might not be the most important. Still
I think merging them quickly is important - new developers now often
wait months before their trivial changes get merged, which likely
discourages them from contributing more.
I think it's important to have someone to guide development effort,
and keeps the larger picture in mind. I don't think Andy has even
indicated before which issues are the most important to him. I think
it'd be more useful for Andy to give high-level comments, and take
parts in discussions like this one, than to worry about individual
colors or zoom levels or syntax errors in pull requests. Perhaps he
also could document some of his vision in the CONTRIBUTING.md file
I do think it's good that commits are being reviewed. We quite often
catch issues in pull requests, so allowing everyone to commit might
not be the best idea. Also, we have people with different areas of
expertise: cartography, software development, database design, etc. So
the discussions are in my opinion usually a good thing - not only do
they improve the map, but I also have learned a lot from them.
My suggestion would be to allow collaborators to merge PRs of others
(but not their own). Perhaps we could also require a week for feedback
before they are being merged. Many PRs have received useful feedback.
I also don't mind extending the list of 'collaboratos' (currently Paul
Norman, Mateusz, Andy and me) if others are interested. Perhaps we
could try this policy for two months, and then evaluate whether we
need a stricter or even more lenient policy?
Of course, Andy can still do a quick high-level review when deploying
a new version. I don't think deploying automatically, as in the
Osmarender case, is a good idea. Deploying quickly is in my opinion
not as important as merging quickly. Deploying once per month, or even
less frequently provided we have a worldwide testing server, would be
fine with me.
If we let more people commit, we can also consider creating an
acceptance branch, or use one-week feature stops (like JOSM does)
before deploying, so that we don't introduce too much bugs into the
Finally, I also agree that we do need a testing server with worldwide
data. Testing worldwide is impossible on a consumer grade pc, so we
cannot expect contributors to arrange this themselves. Especially for
the low zoom levels, being able to test worldwide is important. I'm
not sure who we should contact to discuss this?
More information about the dev