Glen Choo <chooglen@xxxxxxxxxx> writes: > At $DAYJOB, we observed that this topic breaks MacOS builds with sha1dc: Thanks for a report. How dissapointing. The thing is that the topic has been in 'next' since the 11th (i.e. early last week), and I know that you guys rely on the tip of 'next' in working order to cut your internal releases, but we did not hear about this until now. What makes it taste even worse is that nobody else caught this, even though we seem to have a couple of macOS jobs at GitHub Actions CI, there we didn't see any breakage related to this. Possible action items: * See what configurations our two macOS jobs are using. If neither is using sha1dc, I would say that is criminal [*] and at least one of them should be updated to do so right away. * The "two macOS CI jobs sharing too many configuration knobs" may not be limited to just SHA-1 implementation, but unlike Linux builds and tests, we may have similar "monoculture" issue in our macOS CI builds. Those users, who depend on macOS port being healthy, should help identify unnecessary overlaps between the two, and more importantly, make sure we have CI builds with configuration similar to what they actually use. * Adding a few build-only-without-tests CI jobs also might help. * Those who depend on working macOS port, especially those with corporate backing who choose to use configurations that are different from what we have CI builds for, are requested to arrange a more frequent build test to catch a problem like this much earlier. Anything else I forgot that we can do to improve the situation? I personally do not use macOS, I am not interested in using one, but I do value those who choose to use macOS have happy git working on their platform, so the stakeholders need to chip in. Thanks. [Footnote] * Until the world migrates over to SHA-256, the collision detecting SHA-1 implementation is what we must use unless there is a strong reason not to. If we are not testing something that ought to be the default, we are not doing a very good job.
