Mapping SVN usernames to git

[Taylor Smock]

I'm going to throw in my two cents here. Which isn't much. :)

On 11/24/23 4:21 AM, Dirk Stöcker wrote:
> [...]
>> I suggest to throw ideological thinking over board and fully join the 
>> GitHub train. It is not ideal but in my opinion the current situation 
>> is worse, with ancient technology presenting a clear obstacle to 
>> contribution.
> Sorry, but which ANCIENT technologies do you refer to?
>
> The 100% OpenSource software we're using. All of them maintained and 
> updated normally (even if a bit slow in case of Trac). I'm OpenSource 
> developer, that's the reason why I also USE OpenSource software.

I don't remember who asked me first about moving to GitHub when I first 
mentioned I was looking at a `svn` -> `git` migration, but I said that I 
thought it would only happen if there was a significant security 
vulnerability in Trac that was not fixed within a reasonable amount of 
time. And even then, I think we would move to `GitLab` or `Gitea` 
instead, although there might be a brief conversion to GitHub first. On 
a personal level, I don't like GitHub. On a professional level, it is 
what "everyone" uses, so I'm open to patches there /so long as/ there is 
also a trac ticket to reference.

With that said, moving our development repositories to `git` would be a 
required step for moving to any of the "popular" things like GitHub, 
GitLab, or Gitea. I /would/ like to have CI configuration in the repo 
(like GitHub/GitLab CI) since it would make it easier to figure out what 
failed and why -- I don't have to do as much guessing at what the server 
was doing when debugging, especially if the CI is run in an ephemeral 
container. Jenkins does echo out commands, but there have been some CI 
failures that were dependent upon the software installed. Which were a 
PITA to debug.

> I'm pretty sure that actually the opposite is true. Vincent tried to 
> do a gitlab migration and that was a nightmare which he never 
> finished. The current system is clearly structured and manageable with 
> minimum efforts. All attempts to open into the direction of GitHub 
> increased my maintenance efforts instead of reducing them, e.g. that 
> we host plugins at GitHub "because the authors then will care" (which 
> they don't).
I don't know what (exactly) about the gitlab migration was a nightmare, 
but I /think/ it was partly due to not having a good way to transfer 
from Trac to GitLab. I /assume/ he was just going to use the `git-svn` 
bridge to convert from `svn` to `git` (which I'm not doing -- I'm 
deliberately rewriting "history" so that the patch author shows up as 
the patch author for tools parsing git commits, and committed by whoever 
did the commit).
>> Saying "we can only move to git once this list of 100 things is 
>> guaranteed to work from day one" will delay the project to infinity, 
>> and saying "we can move to git but never GitHub" is also a shitty 
>> idea - gives you all the pain without the gain.
>>
>> If Dirk doesn't want to be responsible for the move to GitHub - 
>> something I could fully understand - then maybe it is time to pass 
>> the baton to a new maintainer who is willing to take on the job.
>>
>> The move to GitHub is inevitable. Dirk, the only thing you can 
>> influence is how long it takes and how painful it is for everyone.
>
> The essential question is what would you expect from such a move? 
> Essentially if I loose interest tomorrow JOSM will still work and even 
> without any server access a move to GitHub is possible - it's Open 
> Source. If you move to GitHub you get exactly the same situation as 
> when I'm not there anymore. Though ATM I care for this software for 16 
> years, I wouldn't do that anymore when such a change comes.
>
> I can warrant that a move to GitHub will result in all the services 
> around JOSM going dead and then nobody will care for reimplementing 
> the functionalities. JOSM will be stripped down to the bare software 
> and as that's pretty low quality compared to the current system it 
> will be abandoned step by step.
>
> A GitHub version would have
> * No Plugin handling
This would be true initially. I think the same person who first asked me 
about moving to GitHub also asked about using the GitHub API to get old 
versions. My response was that I would be more inclined to work on that 
if it wasn't a GitHub specific API. Maybe the other git forges implement 
the same API. I don't know, and I haven't gotten around to checking. An 
alternative would be creating a repo that provides plugin handling 
similar to what we have for the plugins distributed via svn. I probably 
won't do that, since it isn't something I see as high impact. So someone 
else (any volunteers? like those who want GitHub?) would have to create 
a GitHub pages site that listens for new releases (and changes to the 
latest version!) from plugins in JOSM GitHub and then produces an 
compatible plugin information dump for JOSM.
> * No Help pages
> * No Maps support
> * No update information / MOTD
> * No Preset handling
> * No Style handling
> * No Rules handling

For anyone that /really/ wants to move to GitHub, I think it is 
possible. You (the person who wants to move to GitHub/something like 
GitHub) will need to set up some kind of mirroring system for the 
various endpoints /keeping attribution/ and possibly supply patches to 
make sites configurable for testing purposes. I /think/ everything but 
`MOTD` and `Help pages` are configurable. Some of those implementations 
may need/want a webhook call, which would require action on the JOSM 
maintainer side in GitHub (I think stoecker would have to do this, 
unless there is someone else with admin privileges on GitHub).

> * Loss of the development history in tickets

I don't think this is as much of an issue as I think you think it is. 
There exists at least one Trac -> GitHub migration tool, and I believe 
it keeps ticket history. The big thing would be deleting/renaming the 
current repo so that the ticket numbers match up.

I'd test it out, but I don't want to overload the server (I don't know 
if it tries to be fast or if it waits some period of time between API 
calls). Even if that migration tool doesn't work, it shouldn't be /too/ 
difficult to write a script that copies the development history; I wrote 
a script that went through tickets looking for patches with attribution 
information.

> * Missing lots a sanity check of code and data

I assume you are talking about sanity checks on the wiki; most of the 
sanity checks for JOSM core are also done in GitHub.


Like you (stoecker) said in an earlier email, and to clarify for 
everyone else:

> There will only be a migration of the trac-plugins repository to git! 
> No GitHub, not Gitea or GitLab or whatever. So you will still have to 
> send patches. Taylor also plans for core, but if that comes, then only 
> after plugins repo was successful, so minimum 1 year in the future. 
This is true. I am, however, also using this to get the information 
together for a conversion of core to git. My current attribution mapping 
files include users for both, partly because I figure many contributors 
to JOSM plugins have also contributed to JOSM. I do have a test repo for 
a JOSM core svn -> git conversion.

Not converting JOSM core does make things a bit trickier -- I was 
intending to use relative URLs for git submodules, specifically so that 
I wasn't hardcoding a specific server. This should still be doable; we 
just need to have a `josm` git mirror on the same server.


I'll be replying to other threads.


For everyone else (like I'm saying in all my replies) all I'm asking for 
right now is a mapping of svn user -> git attribution. I am especially 
interested in a mapping for people who might be attributed with a `patch 
by <foo>` line. The first responder also included their OSM username, 
which ended up being how they had been attributed.


Have a good day,

Taylor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xD375E00E46192713.asc
Type: application/pgp-keys
Size: 3179 bytes
Desc: OpenPGP public key
URL: <http://lists.openstreetmap.org/pipermail/josm-dev/attachments/20231127/b873db9f/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/josm-dev/attachments/20231127/b873db9f/attachment-0001.sig>