Mapping SVN usernames to git

[Dirk Stöcker]

Hello,

> I changed the way I work many times over the years and for JOSM I even 
> allowed changes which I thought were wrong when other team members 
> requested them vehemently enough. Usually I had to care for the fallout 
> later, sometimes I was wrong.
> 
> One thing was always true: I NEVER requested a project to change the 
> way it works, so that I can contribute. I adapted my style to the 
> project rules or I did not contribute.
> Just to clarify, why I personally requested those changes: They were 
> not for the way I add my contributions. I suggested those, because I 
> noticed how hard it was to set up JOSM for GSoC students (and of all 
> other people interested in development).

JOSM isn't the right software for GSoC students. That's why I always 
suggested to write a plugin in such cases when someone wanted a GSOC 
project.

> I can contribute to JOSM (although some of my contributions did not get 
> applied, due to the complexity of patch management, which led to a lot 
> of frustration and loss of enthusiasm on my side and probably has 
> contributed a lot to me not contributing any more - I like contributing 
> to open source for free, but when writing for the trash can, I rather 
> take some money for it).

Your case is a relatively good example of how NOT to contribute to JOSM. 
You did something and submitted a patch. Then you did something else and 
submitted a patch which depended on the first one and so on. As a result 
you submitted lots of stuff which was a big glob not separable. That 
works for some software, especially when in early development stages, 
but for JOSM the chance that any change destroys something is much high 
than that it does something good. So no high speed many changes approach 
possible. If you try it anyway you'll go away discouraged as you code 
will rot in one of the tickets.

> Yes, it is exactly those 60 Minutes that are the problem: Reviewing a 
> text file, applying it as a test, reverting since there is an error, 
> writing that error back into a discussion, then after getting a new 
> patch making a diff of the patches, then applying again, then running 
> the relevant tests locally to see if they work, then ...
> 
> All things that a modern CVS (git, mercurial, ...) has branches for 
> (except for running the tests: For this, you include a CI configuration 
> for "forks")

A second reason why you should NOT contribute to JOSM. You assume that 
CI and automatics solve anything. Review for me means "Understanding 
what the proposed code does and how that affects the software". There is 
no amount of automatics that can reduce that.

I do not even start with "applying it as a test" until the review is 
essentially finished. Such a type of error I can fix myself when 
applying. No need to inform the author about it at all.

> The problem is not moving JOSM to GIT itself, the problem is a lot of 
> custom-build tooling around the Repository/Trac that hardcodes SVN and 
> that will break. And the problem was, that "none of the old stuff may 
> break". For those not participating in that long, long discussion: One 
> idea was to move away from having two independend build systems (ANT + 
> Eclipse) that are not really popular any more to a generic one 
> supported by most modern IDEs (maven or gradle) with the idea of not 
> having to maintain the two old ones. We aborted this because a 
> requirement would have been, that both old build systems still work.

Even after all these years you don't understand the problem. It's not 
that the tooling is relying on SVN. It's the fact to GitHub or any other 
plattform doesn't provide the features at all. You're always only 
talking about the source code. Well, the source code of JOSM is only the 
smallest part of what the JOSM server does. But to change that small 
part you and the others always request to throw away everything else. 
You've never been able to view above your horizon. And you never 
understood that I request OpenSource to be Open which means it should 
rely on Open Source toolchains.

>> OpenHUB estimates it with over 200 years of developers effort
> 
> Of which is 50 Years hand-writing SVG files. And 10 years that someone 
> took to type all of the webatlas response into a text editor. So I take 
> it back: Applying the patches by hand is not such a big deal, there are 
> other things we need to work on 😂 So if we continue comparing it to 
> sending text letters around, we might stay at the current workflow for 
> quite some time.

Talking bullshit. End of discussion.

For Freedom In Peace
-- 
http://www.dstoecker.eu/ (PGP key available)