[OSM-dev] Release openstreetmap-carto v2.25.0

Mateusz Konieczny matkoniecz at gmail.com
Thu Dec 11 17:25:31 UTC 2014


> A test environment with worldwide data.

Is it feasible that OSMF or somebody else can fund it? Obviously it would
be also necessary to maintain it and change development schedule from
"merge round, than deploy map" to something like "merge round, deploy
new version on test server, if tested version is OK and nobody found new
bugs
deploy tested version on production server".

(Maybe I am wrong in diagnosing what is the main blocker for it).

> But these are just implementation details. The bigger problem is that
> after 2 years of work we're not making much progress on the most
> important things.

For me fixing big part of label mess (low zoom after this release is much
better,
landuse label scaling and sorting was a giant improvements) and
fixing how footways are displayed on lower zoom levels were significant
improvements.

> trunk roads in forests

In this case it would help to announce at some point that it is a good
moment to
submit some PRs (current status is
"building and landuse colours should be looked at first"[1]). Also, it
would be good
to know whatever proposals should attempt to resurrect UK map style with
blue
and green roads - or is it maybe OK to propose a completely different style.

> Should
> I be delaying more PRs until I get time to tweak them? Or should I
> stop reviewing the PRs entirely and just merge any of them that don't
> cause syntax errors?

Obviously, both extremes would be bad. I have no idea how much time you
spend
on reviewing PRs, but current model of PR handling seems good given limited
time (what makes impossible to merge/comment on/reject every single one
waiting).

But maybe it would be a food idea to sometimes start from old ones, not
new?
Because currently PRs that failed to be decided in the first merge session
after
submitting are waiting a long time
- https://github.com/gravitystorm/openstreetmap-carto/pull/725 is an extreme
example of a really unfortunate one (waits since July, it was first attempt
to
contribute by this person).

Also, there are some that were not good enough to assign for merge review
or
bad enough to close. As result for example
https://github.com/gravitystorm/openstreetmap-carto/pull/82
was submitted in 2013 and is still waiting.

> So I pose a question that's most pressing on my mind - should the
> other maintainers be merging PRs without me reviewing them first? Will
> this lead to a better result?

I am not sure. Minimum for these new additional method of merging for
minor changes may be for example:

(1) at least two maintainers reviewed PR and see  comment that
there are no problems with it. For example:
- one maintainer proposes and reviews PR and second reviews and merges it
- somebody else proposed a change, first maintainer reviews it, second
reviews and merges it.

(2) PR waited at least week and nobody posted on github comment in PR
thread that there is something wrong with it (week since second maintainer
posted that it is OK).

Probably every PR should have also (3) some form of before/after comparison
(I am not sure is it OK have "can use Tilemill and git" as prerequisite for
commenting).

But I am not sure how much time would be really saved (fix text-dy change is
probably not time-consuming to review, and anyway it would be necessary yo
control what was changed). Also, what is limit of "minor change"? text-dy
fix?
New icon? New feature? Small tweak for landuse colours?

Maybe my proposal is overly cautious and formalistic? Maybe it is a bad
idea to
allow more people to commit as even now there are too often cases of bugs
and
we should start from test server?

[1]
https://github.com/gravitystorm/openstreetmap-carto/issues/102#issuecomment-61472004


2014-12-11 16:16 GMT+01:00 Andy Allan <gravitystorm at gmail.com>:
>
> On 11 December 2014 at 12:10, Christoph Hormann <chris_hormann at gmx.de>
> wrote:
> > I am somewhat reluctant to bring up this problem since i think the more
> > active development is a good thing in total and i don't want to
> > badmouth this.
>
> I'm glad that you bring this up, please don't be reluctant! I know
> that the development process for openstreetmap-carto could do with
> some improvements.
>
> First subject: The merging of changes. My normal process it to go to
> the list of pull requests assigned to me, and then work down them from
> the top down, i.e. dealing with the newest things first.
>
>
> https://github.com/gravitystorm/openstreetmap-carto/pulls/assigned/gravitystorm
>
> I first try to merge anything that's complicated, like a refactoring.
> Small changes like changing zoom levels of an icon are easier to redo
> later on if there are merge conflicts.
> Secondly I merge any small 'no brainers' like fixing text-dy. There's
> no need for them to wait.
> Then I do other things, starting with stuff where I'm happy with the
> fix and they can be merged with no conflicts.
> Then I start working through any of the above that now needs manual
> conflict resolution.
> Then I revisit things that I've passed over - things that take more
> thought, or where I'm considering rejecting the pull requests or
> asking for modifications.
>
> It seems elaborate perhaps, but it's basically just me trying to get
> as many things merged in the limited time that I have available.
>
> From that it would be a reasonable conclusion to think that I'm being
> a bottleneck on the development - well, perhaps I am. But what is
> frustrating me most is that I end up spending all my time working on
> pull requests that I simply don't think are the most important tasks,
> but there are so many of them (and so many calls for me to hurry up
> with the reviews) that I never actually work on anything else. The
> time I'm not spending reviewing and merging PRs I'm instead spending
> wading through all the comments on issues, which are still running at
> over 100 a week.
>
> But these are just implementation details. The bigger problem is that
> after 2 years of work we're not making much progress on the most
> important things.
>
> The style we have now is pretty much the same as it was two years ago.
> We've made hundreds of changes and I'm a fan of iterative development,
> but I'm not sure that we're iterating in any particular direction. I'd
> love to "sort out" the mishmash of colours, but I'm disheartened by
> how long it is taking us to sort out just the buildings, and solving
> the 'trunk roads in forests' and the hundred other problems like this
> seems a long way off. Even when we're changing small things we get
> bogged down in endless debates and scrutiny, and unfortunately all the
> debating doesn't actually lead to significantly better results.
>
> I don't like reviewing the pull requests. It's not fun. Almost every
> one I merge I think that I'd have done something slightly differently
> - an extra zoom here, a different colour there, a changed icon etc.
> I've deliberately tried not to bikeshed every single pull request and
> so ended up merging a lot of stuff that's not quite to my taste or
> changes that aren't entirely cohesive. Am I getting this wrong? Should
> I be delaying more PRs until I get time to tweak them? Or should I
> stop reviewing the PRs entirely and just merge any of them that don't
> cause syntax errors?
>
> One thing that I'm still sure of is that we need a *team* of
> cartographers. There are too many things in the map, and too many
> ideas and discussions for the style for it to be run by just one
> person. And the work that we're doing now is 10 times more than I
> could do without the help of everyone who is working on it. But I
> don't know how best to organize ourselves. And I'm still unsure if
> it's possible to have a consistent, coherent, nice and yet detailed
> map with dozens of people making iterative changes. I hope it is!
>
> So I pose a question that's most pressing on my mind - should the
> other maintainers be merging PRs without me reviewing them first? Will
> this lead to a better result?
>
> If anyone has any advice, I'm all ears.
>
> Thanks,
> Andy
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20141211/2db91316/attachment-0001.html>


More information about the dev mailing list