ESR Switches To Threadripper But His GCC SVN-To-Git Conversion Could Still Take Months

[goldenleaf]

Wow man, that was pretty harsh criticism.

[Terrablit]

I just took delivery of a newer, faster surgical machine - an AMD
Threadripper cranking 4.2Ghz on 64 hardware threads (thank you, System76 for the donation). I upgraded specifically to tackle the GCC problem.

Oh good, someone upgraded ESR's tools again because he blamed his constant failures on them. Wonderful.

Back at the end of 2014 he got a free custom computer from Tek Syndicate explicitly for "repository surgery". At least part of it was funded with donations. Specs:

• 3.5Ghz Xeon E5-1650v3 (6 core Haswell with HT)
• 32GB PC4-2133 DDR4 ECC Ram
• 512GB M.2 PCIE SSD
• 3TB HGST NAS drive
• 1000W PSU

It's not a monster by today's standards though it would've been a really strong, expensive contender for the time. It's also still significantly better than what most people start with. There's a video on Youtube about it (titled "Build: Linux Workstation for Eric S. Raymond | Meet To Mega Therion"). I don't suggest you watch it as it's beyond tedious, but the info's there if you want to verify for yourself.

Early benchmarks on repocutter-in-Go suggest I'll get at least a 15x speedup relative to the Python version of reposurgeon, possibly rather more.

Is that before or after he got another free high-end workstation? I think I remember this "benchmark" number from the last time he dodged responsibility, so I'm guessing before.

The main source of uncertainty here is how long it will take me to finish the Go translation of reposurgeon. Once that's done I don't expect a finished conversion to take more than a couple of weeks to produce. The good news is the translation is now over 90% done; the bad news is that the part still pending includes the part you really care about, the Subversion dump interpreter.

Why on earth is he (re-)writing a tool that will still take him several weeks to get usable output from? Also, it's good that he did all the easy work. Normally that's not something to complain about, but it's been nearly a year with no progress and all he's done is whine, get free shit, do the easy stuff, and take credit.

I realize this may not be the best place to ask, but the most effective way to speed things up would be to second me somebody with Go skills to help with finishing and debugging the translation. The blocker is not Go knowledge per se, it's the intrinsic complexity of the code I'm translating. Even with my skills and domain expertise this is a tough job.

I will further add that a really motivated expert C programmer would do for the help. Go is an easy enough transition for a C expert that it would be practical to learn the language while assisting with this.

And now he needs help, of course. Not because he doesn't understand Go, but because the code he wrote is so complex. Last time this came up, people popped into the reposurgeon repo and found it was a bunch of borderline-unmaintainable spaghetti code. It's not a difficult problem or a complex solution, but a bad implementation with most of Reposurgeon being the code in the 637KB "reposurgeon" file with 14K lines in it.

Good news, though, he's writing his new golang replacements in the same git repository in the master branch because of course that makes sense. Keep in mind, he's really good at Go. That's why he's only been working on porting this shit code for 9 months. First commits on the Go version of repocutter is from 2018-08-23. It's okay, though, it was his computer slowing him down, so he got a free one just to figure out he still needs help.

Please, no one give him anymore free stuff just because he whines. We have kernel developers contributing far more useful code who are stuck on far worse systems than the ones he has to upgrade from. Also, please don't assign him any more important blocking tasks. And for goodness' sake, don't accept his opinions. Less than 20% of what he says has any value.

[Michael]

Isn't this a one time conversion? Or are they going to have to do this repeatedly? If it's one time-- or even less than 10-- it seems like a good solution (read: cheaper) for throwing a large cloud VM at it and just letting it brute force things...

It's one-time. once they transition to that Git workflow.

[Ericg]

Isn't this a one time conversion? Or are they going to have to do this repeatedly? If it's one time-- or even less than 10-- it seems like a good solution (read: cheaper) for throwing a large cloud VM at it and just letting it brute force things...

[phoronix]

Phoronix: ESR Switches To Threadripper But His GCC SVN-To-Git Conversion Could Still Take Months

It looks like the saga of converting the GNU Compiler Collection (GCC) source tree from SVN to Git isn't over yet and could still take months until completion...

http://www.phoronix.com/scan.php?page=news_item&px=ESR-Threadripper-GCC-Git