[josm-dev] GSoC application for JOSM core

Dirk Stöcker openstreetmap at dstoecker.de
Sat Mar 19 11:02:00 UTC 2016


On Fri, 18 Mar 2016, Michael Zangl wrote:

>>> Those are the tasks I identified and of which I think that they can fill
>>> a summer - a lot of the work will be required for backward
>>> compatibility, testing and fixing bugs.
>>> https://docs.google.com/document/d/1CfGQBtsTljYg0N56sjeomZVRPTasyLoaAqVgbwDmzKs/edit?usp=sharing
>>
>> You're sure this only fills a summer?
>
> I am pretty sure I won't get even close to what I personally would like
> to do, but it should be a good starting point.

Students - Estimated times are always so optimistic. Reality usually 
multiplies that by 3 or more ;-)

>From the document above it's fine to have multiple goals, but I think you 
should group that into
  * must be reached
  * should be reached
  * nice to have
so that in case of short time you can focus more on the important parts.

Also keep in mind that the constant integration approach means that you 
have to write code which will or may be dropped in later steps of the 
development again.

> Nice to hear. I am worried most about breaking plugins, especially the
> ones that do not use the documented API but assume some internal state
> of JOSM. I won't be able to test them all or even know of them.

JOSM has no stable API. This is a design decision which has advantages and 
drawbacks. Advantage is that plugins can do nearly everything. Drawback is 
that plugins do nearly everything. :-)

Our solution to this is that JOSM core comes first. We do what's 
necessary. If we break used APIs, then we fix the plugins in SVN (and 
github openstreetmap project). Plugins not in these repositories must be 
fixed by their authors.

We try to add deprecation warnings to ease this approach, but it's not 
required.

So: Caring for plugins is needed, but it should not stop necessary changes 
in the core.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)



More information about the josm-dev mailing list