Proposal for the transition timetable for the move to GIT
Eric S. Raymond
Mon Dec 16 23:19:00 GMT 2019
Segher Boessenkool <firstname.lastname@example.org>:
> 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
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the Gcc