Proposal for the transition timetable for the move to GIT

Eric S. Raymond
Mon Dec 16 23:19:00 GMT 2019

Segher Boessenkool <>:
> There is absolutely no reason to trust a system that supposedly was
> already very mature, but that required lots of complex modifications,
> and even a complete rewrite in a different language, that even has its
> own bug tracker, to work without problems (although we all have *seen*
> some of its many problems over the last years), and at the same time
> bad-mouthing simple scripts that simply work, and have simple problems.

Some factual corrections:

I didn't port to Go to fix bugs, I ported for better performance.
Python is a wonderful language for prototyping a tool like this, but
it's too slow and memory-hungry for use at the GCC conversion's
scale.  Also doesn't parallelize worth a damn.

I very carefully *didn't* bad-mouth Maxim's scripts - in facrt I have
said on-list that I think his approach is on the whole pretty
intelligent. To anyone who didn't have some of the experiences I have
had, even using git-svn to analyze basic blocks would appear
reasonable and I don't actually fault Maxim for it.

I *did* bad-mouth git-svn - and I will continue to do so until it no
longer troubles the world with botched conversions.  Relying on it is,
in my subject-matter-expert opinion, unacceptably risky. While I don't
blame Maxim for not being aware of this, it remains a serious
vulnerability in his pipeline.

I don't know how it is on your planet, but here on Earth having a
bug tracker - and keeping it reasonably clean - is generally 
considered a sign of responsible maintainership.

In conclusion, I'm happy that you're so concerned about bugs in
reposurgeon. I am too. You're welcome to file issues and help us
improve our already-extensive test suite by shipping us dumps that
produce errors.
		<a href="">Eric S. Raymond</a>

More information about the Gcc mailing list