[josm-dev] Integrating notes into JOSM core

[Toby Murray]

The answer to all of Paul's comments is "because that is how the OSB plugin
worked" :) But they are all UI issues and like I said, I don't think much
of the UI code from the current plugin will make it into core so that can
certainly all change after the back-end processing code is in place.

As for the comments about my process:
I agree, it isn't really a great way of doing things. However I am
unwilling to do development on a feature like this in an environment where
I can't commit often and at will. Since the code isn't going to be stable
for a little while, I don't want to submit patches through trac early on
and then have to re-patch everything 5 times.

This type of feature development is the reason why branches exist in
version control systems. But you don't seem to use branches. Sooo... that's
why I'm doing it on GitHub where I can branch and commit all I want until
the code is reasonably stable at which point I will file tickets in trac.
It may only be a couple of days or it might be a little longer depending on
how much time I have. I will definitely try to split things up as much as
possible and submit more smaller patches and not one giant one at the end.

The good news is that I think a lot of the changes (at least initially)
will be new classes so I don't think there will be too many problems with
conflicts and such.

Toby


On Sun, Aug 24, 2014 at 3:49 PM, Dirk Stöcker <openstreetmap at dstoecker.de>
wrote:

> On Sun, 24 Aug 2014, Toby Murray wrote:
>
>  My eventual vision is that instead of the download-as-you-pan nonsense,
>> Notes will be listed as a checkbox alongside "OpenStreetMap Data" and "Raw
>> GPS Data" checkboxes in the download dialog. But this checkbox can not be
>> added by a plugin so this weekend I decided to take a look at how things
>> might fit into core.
>>
>
> We always offered to integrate patches for JOSM core which make life
> easier and we'd like to have that functionality in core. But I don't
> remember many such requests till now although some tickets suggest there is
> potential.


>
>  not the case. But in order to make it easy for people to see what I have
>> so
>> far, I have forked the JOSM git mirror on GitHub and am pushing changes
>> there. When things are done we can work on porting the changes to SVN.
>>
>
> That actually is not a very good way. Nobody likes to accept larger blobs
> of changes and we don't do that as well. If you have proper change
> requests, make a patch and a ticket for it and when sensible it will be
> integrated. Doing larger changes first and at the end thinking about an
> integration is a good road for failure.


>
>  Depending on time constraints, I am thinking this might actually end up
>> being a multi-step process. The back-end API interactions could be
>> integrated into core first and the notes plugin could switch to using core
>> for those functions before any GUI changes are introduced in core.
>>
>
> If it already works this way, then also do it this way and not in a fork
> of the codebase (which does not mean you cannot use the git mirror, but be
> aware, that your changes there should find their way back to the core SVN
> instead of accumulating). In principle we also accept a small amount of
> code which is not directly necessary for core function and what we always
> accept whe needed are changes which make plugin functions possible (i.e.
> switches from private to public or new interface functions instead of
> variables).
>
>
>  Next I need to look at how to integrate the API interactions into core.
>> I'm
>> still trying to understand the interactions between OsmApi,
>> BoundingBoxDownloadeer, OsmServerReader and the Download*Task classes so
>> I'm not quite sure in what direction I'm headed on that yet. Suggestions
>> are of course welcome :)
>>
>
> Do task-by-task (i.e. ticket by ticket) requests in these cases. Propose a
> fix (and a description WHY) and see what the result will be. It will not
> always be what you expect, but it will solve the issue at hand.
>
> All together - it is fine you want to get that into core and it will be
> smooth if you try continuous integration.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>