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

[Christoph Hormann]

On Wednesday 10 December 2014, Matthijs Melissen wrote:
>
> Today, v2.25.0 of the openstreetmap-carto stylesheet has been
> released [...]

First of all these remarks don't have much to do with the changes of 
this release in particular, it is mostly that this has confirmed a 
number of observations i have made in the last months.

It seems to me that with the more active development of the style in the 
past year or so with frequent changes with high visual impact the mode 
of development of the style as it is currently practiced has reached a 
limit where it becomes very difficult to develop well composed changes 
to the style at all.

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 have not done a precise statistical analysis but the time for a change 
from being designed to actually being deployed is fairly long, usually 
there are at least 1-2 releases in between, often several months.  This 
does not only mean changes need to be adapted to a changed codebase, it 
also means that the basis in terms of visual design is often changing 
significantly while a change is waiting to be merged.

As a result most changes which are deployed in recent releases are not 
really very well aimed.  They are meant to address certain issues but 
usually introduce at least as many new issues.  Other changes are then 
made later to address some of these with a similar result.  To some 
extent this is inevitable due to the complex interactions within the 
style but it is also largely a result of 'shooting at a moving target'.

I don't have a real solution for this problem but there are a number of 
things that IMO could much improve the situation:

(1) Systematic followups on the success and side effects of changes.  
The only case where i remember this happening is with the landcover 
labeling [1] but note that the majority of the issues pointed out there 
are not yet addressed now, two month later.  IMO development ressources 
should in most cases focus on bringing a change to a satisfying overall 
conclusion before working on new changes.  For most of the recent high 
impact changes this is not the case.

(2) Stricter queuing of changes for deployment.  The manner in which 
pull requests deemed ready for merging are selected for deployment 
seems quite random at least to the casual observer.  Some are merged 
within days, others take several months (the oldest one currently seems 
to be from July [2]) Followups on previous changes should probably be 
given priority.

(3) A test environment with worldwide data.  I know this is not a new 
suggestion and mostly a problem of ressources.  What would already 
help, especially for systematic followups on changes and would probably 
require much less ressources is a frozen tile cache that allows better 
before-after comparisons for changes already deployed.

[1] 
https://github.com/gravitystorm/openstreetmap-carto/pull/941#issuecomment-58766694
[2] https://github.com/gravitystorm/openstreetmap-carto/pull/725

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

[Andy Allan]

On 11 December 2014 at 12:10, Christoph Hormann  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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

[Sven Geggus]

Andy Allan  wrote:

> 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?

Hm, with osmarender we already had something like this in the past. Back
then I always hoped that I did not break anything when doing a commit to
openstreetmap svn because it went live automatically on the next update of
tiles@home.

It has arguably always been more ugly than even the mapnik style of that time, 
but it
but tended to be some kind of an "all in one" Open-street-map.

So probably we should fork and go for two different styles with a different
maintainer model again.

BTW, I'm also still looking for a less annoying way to maintain the german
style which is basically a fork of your style starting from various versions.

Sven

-- 
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
  about porting their Database to Linux)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

[Mateusz Konieczny]

> 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 :
>
> On 11 December 2014 at 12:10, Christoph Hormann 
> 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

[OSM-dev] [meta] Problem with reply to messages from mailing list on Gmail

[Mateusz Konieczny]

I have a problem with mailing list - using "reply" is addressing e-mail to
just person
that submitted message, not the entire mailing list.

http://webapps.stackexchange.com/questions/37046/making-gmail-to-use-reply-all-automatically-in-mailing-list-replies
indicates that there is no easy fix

Surprisingly replying to messages from tagging mailing list are
automatically addressed
to mailing list, despite the same addressing scheme.

Is there some known fix for this issue (so reply to e-mail for dev ml will
work like
replying to tagging mailing list) beyond "stop using gmail, start using X"?
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [meta] Problem with reply to messages from mailing list on Gmail

[Bryan Housel]

No, it has nothing to do with Gmail.. 
Reply-to “munging" is a setting in Gnu Mailman, the mailing list software..
http://www.gnu.org/software/mailman/mailman-admin/node11.html 


Historically people have very strong opinions about whether mailing list 
replies should go to he original person or to the list.  So you just have to 
pay attention, or always hit “reply all” if you want to reply to the list.



> On Dec 11, 2014, at 12:32 PM, Mateusz Konieczny  > wrote:
> 
> I have a problem with mailing list - using "reply" is addressing e-mail to 
> just person
> that submitted message, not the entire mailing list.
> 
> http://webapps.stackexchange.com/questions/37046/making-gmail-to-use-reply-all-automatically-in-mailing-list-replies
>  
> 
>  indicates that there is no easy fix
> 
> Surprisingly replying to messages from tagging mailing list are automatically 
> addressed 
> to mailing list, despite the same addressing scheme.
> 
> Is there some known fix for this issue (so reply to e-mail for dev ml will 
> work like
> replying to tagging mailing list) beyond "stop using gmail, start using X"?
> ___
> dev mailing list
> dev@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/dev 
> 

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [meta] Problem with reply to messages from mailing list on Gmail

[Tom Hughes]

On 11/12/14 17:32, Mateusz Konieczny wrote:


I have a problem with mailing list - using "reply" is addressing e-mail
to just person
that submitted message, not the entire mailing list.

http://webapps.stackexchange.com/questions/37046/making-gmail-to-use-reply-all-automatically-in-mailing-list-replies
indicates that there is no easy fix

Surprisingly replying to messages from tagging mailing list are
automatically addressed
to mailing list, despite the same addressing scheme.


The tagging list is probably configured to set Reply-To and this one 
isn't (it's a per list option).


No matter what anybody will tell you (and please, let not have the 
Reply-To for mailing lists flame war yet again) there is no right answer 
as to whether or not to set it. People have been debating it for at 
least twenty years.


Anyway, I just tried gmail, and "reply to all" certainly included dev 
for this message as I would expect. Reply doesn't obviously.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [meta] Problem with reply to messages from mailing list on Gmail

[Mateusz Konieczny]

Thanks - I will try to keep using "reply to all".

> and please, let not have the Reply-To for mailing lists flame war yet
again

OK, so it is one of Dangerous Topics Utterly Pointless to Debate.
I will avoid it and thanks for a warning.

2014-12-11 18:47 GMT+01:00 Tom Hughes :
>
> On 11/12/14 17:32, Mateusz Konieczny wrote:
>
>  I have a problem with mailing list - using "reply" is addressing e-mail
>> to just person
>> that submitted message, not the entire mailing list.
>>
>> http://webapps.stackexchange.com/questions/37046/making-
>> gmail-to-use-reply-all-automatically-in-mailing-list-replies
>> indicates that there is no easy fix
>>
>> Surprisingly replying to messages from tagging mailing list are
>> automatically addressed
>> to mailing list, despite the same addressing scheme.
>>
>
> The tagging list is probably configured to set Reply-To and this one isn't
> (it's a per list option).
>
> No matter what anybody will tell you (and please, let not have the
> Reply-To for mailing lists flame war yet again) there is no right answer as
> to whether or not to set it. People have been debating it for at least
> twenty years.
>
> Anyway, I just tried gmail, and "reply to all" certainly included dev for
> this message as I would expect. Reply doesn't obviously.
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [meta] Problem with reply to messages from mailing list on Gmail

[Matthijs Melissen]

On 11 December 2014 at 17:32, Mateusz Konieczny  wrote:
> Is there some known fix for this issue (so reply to e-mail for dev ml will
> work like
> replying to tagging mailing list) beyond "stop using gmail, start using X"?

In Gmail, under Settings-General, you can change 'Default reply
behaviour' to 'Reply all'. Of course, that will also lead to undesried
behaviour in some circumstances, but I tend to use 'Reply all' more
often than 'Reply'.

-- Matthijs

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

[Matthijs Melissen]

On 11 December 2014 at 15:16, Andy Allan  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
main website.

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?

Kind regards,
Matthijs

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev