You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rename "semantically reproducible build" to something else? #426
There was interest, but many complained that the name "semantically reproducible build" was too easily confused with the term "reproducible builds". The term "semantically reproducible build" is clear enough to me, and I'm personally fine with it. However, I understand the concern by some that it's not clear enough. Having clear terms is really useful.
Would you consider renaming "semantically reproducible build" to something else? Some ideas mooted were:
"semi-reproducible build"
"semantically repeatable build"
"semantically equivalent build"
I think some others would be happier with another term, but I don't know how important the current term is to you.
At least we're not talking about the other hard problem, cache invalidation and off-by-one errors. :-)
I'm fine with changing the docs/text to call it "semantically equivalent build" or similar based on the context, or if we can find a better name that doesn't encroach reproducible-builds, I'd probably be fine with that too.
I think that were then okay with "semantically equivalent" in the documentation, unless we can think up something better in the next few days before I take the time to update the docs.
David A. Wheeler (@david-a-wheeler) I opened #429 to update this in the readme and program strings, and ahve also updated the wiki to use "semantic equivalency".
Thanks so much! I think "semantically equivalent" is great; it's clearly distinct and I think it gives the sense of what's intended.
I'll post to the reproducible-builds mailing list, I think they'll be pleased.
At a future point it would be cool if the tool could report "semantically equivalent" when that is true, and also indicate "reproducible build' (bit-for-bit) when it can find a way to reproduce it exactly. I should probably file that as a separate issue, because that probably is more than just a doc change :-).
Thanks so much! I think "semantically equivalent" is great; it's clearly distinct and I think it gives the sense of what's intended.
No problem. Thanks for the suggestion. I think this makes it very clear.
I'll post to the reproducible-builds mailing list, I think they'll be pleased.
🎉
At a future point it would be cool if the tool could report "semantically equivalent" when that is true, and also indicate "reproducible build' (bit-for-bit) when it can find a way to reproduce it exactly. I should probably file that as a separate issue, because that probably is more than just a doc change :-).
I think that would be a great ability to have - oss reproducible has extensibility via the strategies, I think that would be cool to have checking for bit for bit "reproducible build" be a strategy. I do agree though that that's a larger ask than this update so a fresh issue to track it would be best. If you have any recommendations for what we may be able to leverage to avoid building that strategy from scratch that would also be great to hear.
Activity
gfs commentedon May 30, 2023
Michael Scovetta (@scovetta) thoughts on this?
"Semantically equivalent" seems accurate to describe the methodology/depth of analysis to me, but so does our current "semantically reproducible".
scovetta commentedon May 30, 2023
At least we're not talking about the other hard problem, cache invalidation and off-by-one errors. :-)
I'm fine with changing the docs/text to call it "semantically equivalent build" or similar based on the context, or if we can find a better name that doesn't encroach reproducible-builds, I'd probably be fine with that too.
gfs commentedon May 30, 2023
David A. Wheeler (@david-a-wheeler)
Thanks again for your detailed feedback.
I think that were then okay with "semantically equivalent" in the documentation, unless we can think up something better in the next few days before I take the time to update the docs.
Fix #426
gfs commentedon Jun 1, 2023
David A. Wheeler (@david-a-wheeler) I opened #429 to update this in the readme and program strings, and ahve also updated the wiki to use "semantic equivalency".
david-a-wheeler commentedon Jun 2, 2023
Thanks so much! I think "semantically equivalent" is great; it's clearly distinct and I think it gives the sense of what's intended.
I'll post to the reproducible-builds mailing list, I think they'll be pleased.
At a future point it would be cool if the tool could report "semantically equivalent" when that is true, and also indicate "reproducible build' (bit-for-bit) when it can find a way to reproduce it exactly. I should probably file that as a separate issue, because that probably is more than just a doc change :-).
gfs commentedon Jun 2, 2023
No problem. Thanks for the suggestion. I think this makes it very clear.
🎉
I think that would be a great ability to have - oss reproducible has extensibility via the strategies, I think that would be cool to have checking for bit for bit "reproducible build" be a strategy. I do agree though that that's a larger ask than this update so a fresh issue to track it would be best. If you have any recommendations for what we may be able to leverage to avoid building that strategy from scratch that would also be great to hear.
Thanks
Gabe
Fix microsoft#426 (microsoft#429)