Mapping SVN usernames to git

[Dirk Stöcker]

Hello,

> I know that Dirk has built a ton of "handmade CI-like stuff" on top of 
> the trac/svn system and not all of that will easily transfer, but as 
> long as it doesn't, we will always have the situation that Dirk has to 
> maintain the system and Dirk is the only person to understand how 
> maintaining it works and therefore it will never change.

No. That's not true. Everything is pretty straightforward. SVN, Trac, 
Nexus, Jenkins and Sonar are standard installations. There are many Trac 
plugins which provide a lot of services, but they are relatively 
straightforward (even if not OpenSource). Each of them has a different 
task and only cares for this task. Also the most important things are 
properly documented and scripted, so that it would be pretty easy to 
install the whole system from scratch on a new server from the backups. 
I made sure that I'm not the single point of failure.

> This is not a healthy situation - a "bus factor of 1" and it needs to 
> be fixed.

There where two people, but the interests of Vincent changed (or it was 
something more grave) in the last years and thus it's back to one. 
Taylor is now another active contributor, so there may come a time next 
year when he wants, that he gets the permissions necessary to replace 
Vincent as my wing man ;-)

It's not that I consider passing such privileges lightly, as in the past 
I had to care with the fallout when I did this.

There are others who have a lot of permissions for the normal operation 
(i.e. not needed server access). Though like always also these come and 
go.

> 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 know that JOSM has had its share of people who want to re-do 
> everything as a condition for their contribution, and frequently told 
> them to leave us alone when I was the JOSM maintainer. But I mainly 
> said that to people who wanted to (in my opinion) make the whole thing 
> more COMPLEX. I always said: We need to be able to attract as many 
> contributors as possible and keep the hurdles low, so please don't 
> re-engineer all this to a point where only people with 10 years of Java 
> experience can work on it.
> 
> But we now have a point where the arcane SVN/Trac/homemade CI stuff is 
> the complex bit, and a move to GitHub would simplify things and open 
> doors for new people.

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 would be in favour of expediting the move to GitHub, and if this 
> breaks a few things for a while (because Dirk has created so much 
> automation that somehow parses Trac Wiki entries that flow into JOSM 
> configuration and whatnot) then so be it - let things be broken for a 
> while until someone fixes it. And it doesn't have to be Dirk all the 
> time. Dirk, you could take a deep breath and allow a new generation to 
> make their impression on JOSM. They'll get it working, no doubt.

"parses Trac Wik entries" → Sorry, but that's exactly what is NOT done. 
For each and every service there is a proper API. Structured, Clean. I 
now that's how you started the MOTD, but that's long gone. The only 
thing done with wiki pages is display them in internal browser (help 
pages, MOTD and so on).

> 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
* No Help pages
* No Maps support
* No update information / MOTD
* No Preset handling
* No Style handling
* No Rules handling
* Loss of the development history in tickets
* Missing lots a sanity check of code and data

And don't tell me that can be ported. I'm old enough and have seen 
enough "system switches" of other software and the result is that except 
the code itself nothing survives.

So really, what do you think would be the benefit? That a possible 
1-person-failure becomes a for-sure 1-person-failure?

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