...
This text is a formalization and simplification of existing practice that
we worked out in conjuction with the reproducible builds team and that strikes a balance between attempting to enumerate all the causes of nonreproducibility (which would be quite difficult to do) and providing
some clear guidance to maintainers about what types of output variance
they *don't* have to worry about (since obviously packages can't be reproducible under all circumstances and in all environments). The
intention is to set a minimum bar that packages should be trying to meet,
...
This is directly in the center of Policy's normal role of standardizing
and documenting best practice that has been developed elsewhere in the project.
...
The definition is not decoupled from current practice. It is roughly equivalent to the information currently captured in *.buildinfo files
while being easily comprehensible to people who haven't studied
*.buildinfo files.
...
Finally, Policy in no way constrains people from filing bugs or reporting issues (via whatever means, such as tracker.debian.org) in packages about things that are not spelled out in Policy.
...
As Policy Editor (a delegated position), based on my read of project consensus including in-person verification of that consensus at DebConf
17, I am formally declaring that I believe this change has consensus
despite your opposition. We will therefore include this change in the
next release of Policy.
If you have specific wording suggestions that you believe would bring this Policy requirement closer in line with what we're already doing in the project (and which has gotten us to 94% reproducible already), please make them.
This is one of the reasons I do not attend DebConf anymore. We are an
online organization. Consultation should happen online. Metting are nice
but they should not be used to vet consensus and ignore absentees.
So I object to Adrian being overriden on that ground.
But as a technical document, it is lacking practical recommendation for maintainers how to make sure their package build reproducibly and create confusion on the goal by using the term 'reproducible build' when
'robust build' is meant (which is a worthwile goal by itself, but a
different project nevertheless).
But as a technical document, it is lacking practical recommendation
for maintainers how to make sure their package build reproducibly
and create confusion on the goal by using the term 'reproducible
build' when 'robust build' is meant (which is a worthwile goal by
itself, but a different project nevertheless).
On Wed, 16 Aug 2017, Bill Allombert wrote:
But as a technical document, it is lacking practical recommendation
for maintainers how to make sure their package build reproducibly
The practical recommendations for maintainers are encoded separately, as they're evolving. See https://wiki.debian.org/ReproducibleBuilds/Howto
for example.
and create confusion on the goal by using the term 'reproducible
build' when 'robust build' is meant (which is a worthwile goal by
itself, but a different project nevertheless).
I'm not convinced that this change will reduce confusion, as the
reproducible build project has been using this language in Debian for
many years now.
On Wed, Aug 16, 2017 at 12:14:53PM -0700, Russ Allbery wrote:
If you have specific wording suggestions that you believe would bring
this Policy requirement closer in line with what we're already doing in
the project (and which has gotten us to 94% reproducible already),
please make them.
This percentage was reached mostly by fixing software tools (compiler,
doc generators, packaging tools) to be deterministic, rather than by
fixing individual packages. This is a topic that is wholy absent from
policy.
For example policy could mandate that programs that set timestamps
honour SOURCE_DATE_EPOCH.
Bill Allombert <ballombe@debian.org> writes:
This is one of the reasons I do not attend DebConf anymore. We are an
online organization. Consultation should happen online. Metting are nice
but they should not be used to vet consensus and ignore absentees.
So I object to Adrian being overriden on that ground.
That's only a part of what went into this, but I will strongly defend
using the opportunity of in-person meetings to judge consensus. It's very difficult to judge consensus over email because only the strong opinions
are visible. There are frequently situations where there's a large
sentiment in one direction or another that isn't expressed in long threads full of lots of back and forth between a small handful of people who may
or may not have representative opinions.
We can't always do it, and we obviously have to be sensitive to the fact
that not everyone is in the room, but we're also going for consensus, not unanimity. When we have the opportunity to get direction from a large gathering of developers, we should make use of it.
[..]
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 68:51:10 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,379 |