[josm-dev] Common presets for OSM editors?

[Dirk Stöcker]

On Wed, 24 Jun 2015, Paul Hartmann wrote:

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

Well,

- I don't see a sense in involving yet another party. This only increases
   the workload on our side, as we need to verify the backflow. When the
   goal is for editors to work together, than that should also be done. The
   more parties are involved the more work is necessary to keep stuff in
   sync.
- Reestablishing all the infrastructure around including the translations
   is a major task. I know that because I did setup most of it. The current
   proposal simply means all that needs to be redone.
- We have the most sophisticated system of all - Why do we need to
   establish something new to replace it.
- JOSM always did have a level of control of what we present as presets
   and what not. Actually this is wanted from my side and we never
   completely followed Wiki. There must be a good reason to drop that which
   I don't see yet.
- And not to forget: I simply don't trust Ian and the way he can and will
   manage a project.

> For the license issue, it does not matter where the files are hosted.

I refer to the fact, that the GitHub project already stated MIT license, 
which is incompatible to the stuff we have already.

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

Actually ATM I see not a single advantage of a "we replace you stuff with 
a github project" proposal, but many many disadvantages.

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