[Git][reproducible-builds/reproducible-website][master] vienna2025: while going through the old notes, this one was not matching

Sun Oct 4 18:10:57 UTC 2026


Mattia Rizzolo pushed to branch master at Reproducible Builds / reproducible-website


Commits:
420db5ec by Mattia Rizzolo at 2026-10-04T18:19:02+02:00
vienna2025: while going through the old notes, this one was not matching

Signed-off-by: Mattia Rizzolo <mattia at debian.org>

- - - - -


1 changed file:

- _events/vienna2025/agenda/d3-rbdefinition.md


Changes:

=====================================
_events/vienna2025/agenda/d3-rbdefinition.md
=====================================
@@ -26,3 +26,91 @@ RB are a set of software dev practices that create an independently verifiable p
 - "Why?" should be in definition
 - source code doesn't abstract world cases (binary)
 - the definition doesn't hold for everyone
+
+
+
+# WIP below is copied straight from the pad, to merge and turned in markdown
+
+RB Definition
+Notes
+
+Leading the session: Aman
+Taking Notes: Martin
+
+Martin will try to do a pass over these notes after the summits and email the participants to get agreement on the discussion summary, so that we can move the discussion forward from there towards making actual changes to the definition.
+z
+Who is the target audience of the definition?
+
+
+Issues:
+* binary blobs / arranging binary blobs in a reproducible manner
+* what is a build?
+
+* calling artifacts reproducible VS calling parts of the process reproducible
+
+* what is the process that you are calling reproducible?
+
+* making reproducibility claims about defined inspectable boxes?
+
+* It's unclear what a build is. We want to have a triplet: inputs, build instructions, output
+  - you can include the build instructions in the input
+
+* functions can be composable
+
+* inputs to outputs idea is received positively
+
+* input can pe reproducible, process can be reproducible, artifact can be reproduced (form a process)
+
+* input section, output section, builder section
+
+* given the same build inputs and the same build function, the output is bit-by-bit identical
+
+* define abstract machine-evaluatable technical definition then construct a more user-friendly and goal-oriented definition from that
+
+* if i have a bizarre system or impossible build I can confidently make the claim that something is reproducible
+
+* seperate what the reproducible builds movement wants to achieve form the technical definition of reproducibility itself
+
+* people might want to claim my process is reproducible even under a file system that randomizes file order
+
+* something is reproducible if it has been reproduced?
+
+* if something is reproducible, but you need a very specific environment to reproduce it, that makes the property less useful
+
+* we want something that's easily and readily reproducible, that provides enough information about how to reproduce it such that people are able to
+  - clear enough about the process and required inputs
+
+* Practically projects should seek to make reproducing their software easy, cheap and reliable.
+
+Takeaways
+
+* we want to seperate the current definition into (motivation and goals) and a more formal definition of a property
+  - the proerty should apply a build process and not an artifact
+* a simpler more mathematical definition, a more complex goal-oriented
+* martin will write up some suggestion for how to define reproducibiliy based on his work
+* everything that's not explicitly stated as an input to the process should not matter
+* should be defined as a pure function, more mathematical
+
+What we don't like about the definition
+* it does not hold for everyone:
+  - something being reproducible for one person may not mean it being reproducible for another person
+
+
+# Afternoon session
+- Unanimous agreement that the goal and the definition should be separate.
+- We no longer want to include "human verifiable" as part of a property when something is reproducible.
+- Reproducible can be from inputs that are not reproducible or somehow human verifiable, they are two different goals and different properties of build processes.
+
+- We are now unaligned whether we want this isolated definition, some want to exclude some inputs from being allowed, like references to remote artifacts that have to be fetched, and that the process should not be allowed to use the network.
+- Also there is some discussion whether maybe something is supposed to have levels.
+
+- Unclear whether we want to positively list all the things the build is dependent upon, or list all the things the build is independent upon.
+- Unclear outcome...
+
+- We agree with parameterized definitions, unclear whether confirm or deny defaults.
+- One thought is that perhaps we don't want inputs that can be changed externally.
+
+## How to move on:
+- We want more than one word of reproducibility
+- More different terms, or at least split up the current definition in smaller parts
+- Just put it on the notes



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/420db5ec20966a3bb8c4c0fc65c5bfac08ef90f7

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/420db5ec20966a3bb8c4c0fc65c5bfac08ef90f7
You're receiving this email because of your account on salsa.debian.org. Manage all notifications: https://salsa.debian.org/-/profile/notifications | Help: https://salsa.debian.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20261004/ee4af8c7/attachment.htm>
