> 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 <[email protected]>: > > On 11 December 2014 at 12:10, Christoph Hormann <[email protected]> > 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 > [email protected] > https://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
