On 09/02/2013 14:06, Serge Wroclawski wrote:
On Sat, Feb 9, 2013 at 7:33 AM, Steve Bennett<stevag...@gmail.com>  wrote:
No active devs left on this list? Did everyone move to iD?

My impression (and I'm open to correction) is that Richard is focused
on other projects, as well as iD, and that Andy has de-facto become
the PL2 maintainer right now, but has other higher priority.

*updates P2's development status to "It's complicated"*

To me there's absolutely no doubt that, for primetime use as My First OSM Editor, iD is absolutely the way to go. I'd anticipate that it will be ready to take its place as the default OSM editor in the next couple of months and I'm greatly looking forward to the time when it does.

(Disclaimer: although I had a role in pointing it in, I hope, the right direction at first, I'm not really involved in the development of iD at present. I keep an eye and chime in on github tickets now and then, but I've not had the time to get my JavaScript-fu up to the level required to keep up with the Mapbox ninjas. And frankly, that's not at all a problem; they're a million times better coders than I'll ever be, they're making pretty much all the right design decisions[1], they've got the resources both to code it and to inspire a development community, and they're good guys. I couldn't really ask for it to turn out any better.)

So, the question is: what purpose does P2 serve when iD is live and the default?

I think there's two principal niches. One is working with third-party data, as per Snapshot Server and vector background layers. P2 does this very well and there's no support for it in iD. P2 looks like it'll be the go-to solution for projects like the DfT cycling data for a while yet.

Secondly, there's simply the comfort of editing. I find P2 to be a very efficient and enjoyable editor to work with, which is perhaps not too surprising, but there are plenty of others who think so too. A comparable spot in the editor market to Merkaartor, if you like. But we do need to be aware that Flash Player is no longer a given, and I suspect that in a year's time, market penetration even on the desktop will be lucky to hit 80%.

That second reason means that, for me at least, the priority is to get a version of P2 up and running on Adobe AIR. We can, of course, still have an online build too (especially for the third-party data use) and I see no reason why P2 can't continue as a selectable option on the osm.org Edit drop-down. Exasperatingly, AIR on Linux is limited to version 2.6, which I think equates to Flash Player 10.3.

That said, I'm personally not planning to spend huge amounts of time on P2 development in the next couple of months, because there's no urgent priority to do so and I have other things to do. I'm also a bit burned out by OSM right now, partly from six years of dealing with the BAN POTLATCH types and partly from "the whole OSMF shitstorm" (as someone wise called it). So I hope we'll have Potlatch-on-AIR by SOTM, but not by tomorrow, unless that is someone else does it.

For the small remaining time that P2 is the default editor on osm.org, I'm happy to - indeed, would seek to - remain the maintainer of that instance. Any pull requests that can be instantly and confidently merged, I will (and do) merge promptly. Anything that requires a day's work for me to understand isn't going to happen; I can't afford to give a day away like that.

That doesn't, however, stop anyone from running their own forked instances, and indeed that should be valuable in proving that a particular pull request will work or otherwise. So, Steve, I would encourage you to put your own build of P2 somewhere and people can then play with and test that as a prelude to getting them merged into the github.com/systemed repository later.

Personally I think maintaining a standalone desktop editor will be a whole bunch more fun. It frees up P2 to be P2, rather than everyone's first experience of contributing to OSM; it's more realistically forkable (anyone can offer a build for download); the UI doesn't have to be constrained by the browser window; performance should be better; it's less likely to attract the BAN crowd; and we can dump trac and use something sane.


[1] Apart from rendering all nodes, rather than just those in the currently selected way... that's a bit too GIS-like for me. But nothing's perfect, and to have that as my only gripe with it demonstrates exactly how good it is.

Potlatch-dev mailing list

Reply via email to