4 ms·

> C++ has no analogue of the Crater Run as of yet... It does in the form of large organizations with large codebases that try out candidate releases and file b

> C++ has no analogue of the Crater Run as of yet... It does in the form of large organizations with large codebases that try out candidate releases and file bug reports. It's not managed by a central "C++ team" as such if that's what you mean, but there are N independent C++ implementations. At some point we're comparing organizational structure and not technology outcomes.

tialaramex 4y ago
It's like Continuous Integration versus previous practices of "Jim has a working checkout, and I think he built the release version last time, ask Jim to make you a fresh release CD, remind him to switch off the debug symbols though. Oh also I think we're over 650MB now, so he might need to change settings in the CD burner app". It's not that the previous practices didn't work, more or less, it's that they were manual and so you couldn't really rely on them. CI is categorically better, despite being in some sense just an automation of what should be existing practice.
- humanrebar 4y ago
  Except in this case we're literally talking about established CI processes. They're just not triggered by the "C++ contributor" because those don't exist as such. We have GCC contributors, Clang contributors, etc. Periodically a batch of those contributions get marked for testing and they get pushed through various CI processes and bug reports or even PRs get generated. The C++ compiler vendors I am aware of also have access to nontrivial C++ codebases that give them access to these sorts of "see what broke" speculative build jobs: Red Hat has RHEL and CentOS repositories, Microsoft has the presumably massive Microsoft codebases, everyone has access to vcpkg, and so on. I'll also note that this is just normal for sufficiently popular systems languages. If Rust as successful as it seems like it will be, there will some day be far more code outside of public crates than inside them. Anyway, there are some differences for sure, but it's not night and day they way you describe it.

tialaramex 4y ago

It's like Continuous Integration versus previous practices of "Jim has a working checkout, and I think he built the release version last time, ask Jim to make you a fresh release CD, remind him to switch off the debug symbols though. Oh also I think we're over 650MB now, so he might need to change settings in the CD burner app". It's not that the previous practices didn't work, more or less, it's that they were manual and so you couldn't really rely on them. CI is categorically better, despite being in some sense just an automation of what should be existing practice.

humanrebar 4y ago
Except in this case we're literally talking about established CI processes. They're just not triggered by the "C++ contributor" because those don't exist as such. We have GCC contributors, Clang contributors, etc. Periodically a batch of those contributions get marked for testing and they get pushed through various CI processes and bug reports or even PRs get generated. The C++ compiler vendors I am aware of also have access to nontrivial C++ codebases that give them access to these sorts of "see what broke" speculative build jobs: Red Hat has RHEL and CentOS repositories, Microsoft has the presumably massive Microsoft codebases, everyone has access to vcpkg, and so on. I'll also note that this is just normal for sufficiently popular systems languages. If Rust as successful as it seems like it will be, there will some day be far more code outside of public crates than inside them. Anyway, there are some differences for sure, but it's not night and day they way you describe it.