On 23.06.2015 17:23, Dirk Stöcker wrote:
On Tue, 23 Jun 2015, Paul Hartmann wrote:
We already have a mechanism to include previously defined "chunks" by
reference in the defaultpresets.xml file. This could be used to
include presets from the editor-presets.xml file at the correct place
(or not).
Preferably, when we make the includes, the result should be unchanged
or an improvement.
That is unlikely. When the result is the same then it's a license
violation. And to have a start from scratch improve JOSM presets
everywhere which have many man-months work included is impossible.
And a "do the same but slightly modified" I would reject, because that
would invalidate all translators work for nothing.
Given all that, I see no major reason to block this initiative. We
would not drop what we have, but slowly migrating to something else.
You (all) know my opinion about this approach [...].
I know your concerns about abandoning our imagery database. There we
have a comprehensive and well established wiki-based system. A fairly
large number of users contribute imagery sources on a regular basis.
When WMS/TMS URLs change, this gets updated pretty fast. All that with
very little work on our part.
I can understand that it is a risk to drop the wiki-system in favor of a
github repository, where we don't know yet, if we would get to the same
level of participation.
However, you have to acknowledge, that it is a completely different
situation with the core presets. We could, right now, move the
defaultpresets.xml file to a github repository, and include it as an svn
external repository. (As we do for github-hosted plugins areaselector
and conflation to simplify translation.) There is no major technical
reason not to do this.
Therefore I don't understand why you are clinging to the JOSM
infrastructure in this case. It seems natural to start on neutral ground
for a project with a mission to conciliate.
For the license issue, it does not matter where the files are hosted.
I would agree, that the whole project is highly ambitious, because of
the difficulties and workload involved. But if someone (or a group of
people) is very committed, it's not impossible to solve these problems.
As long as we go in small steps and selectively import the parts that
have been unified in a reasonable way, there is no loss on our side.
Paul
_______________________________________________
josm-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/josm-dev
