Adrian Bunk <b...@stusta.de> writes: > I hereby oppose the addition of this to policy.
> It is not true that this would be "Debian's precisification" of > reproducible builds. > The definition does not match any past, present or future practice in > Debian. > Including the people who want this change to policy, there seems to be > noone intending to use this definition of reproducibility. > Adding this to policy would do more harm than good. Let me get the formal part of this out of the way first: 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 disagree, your choices of action are appealing to the Technical Committee under section 6.1 of the Constitution (I'm fine with using that section and letting the TC take a majority vote), or propose a GR under section 4.1.3. Okay, now, why I'm taking that stance: 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, and to lay the groundwork for future work. 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 project is already comfortable with filing bugs against packages for being non-reproducible under this criteria of non-reproducibility, and we already have put significant work into establishing a baseline and have a firm understanding of how close we're currently coming to meeting that baseline. This meets the bar for maturity of work that we look for in major Policy changes. As with many other things in Debian, we hope to improve further later on, and to raise the Policy bar over time as we develop better tools and better understanding, but this bar is one that we can start recognizing with normal-priority bugs right now. The bug severity was specifically chosen to not kick any packages out of Debian and to not make reproducible builds mandatory, simply to recognize them as bugs that we as a project want to see fixed. This feels like the right balance to strike at this point. More work would be required to make them RC. 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. More precision will be possible in the future, but we don't have to wait for that to set the simpler bar. On the consensus side, there was a rare opportunity here to get a measure of consensus from a large section of the project. Holger specifically asked for a show of hands and a show of objections (there were none) for including this standard in Policy, and we had various discussions with other people over the course of DebConf. We have a much better read on project consensus for this than we have for many other things in Debian. 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. This is a core principle of Policy maintenance that we have held to for the more than a decade I've been involed in Policy maintenance. Policy is not an exhaustive list of the possible bugs in packages, and never will be, and Policy will never prevent people from filing bugs against packages at the severity that they think is appropriate. The definition of reproducibility is no exception to this general rule. Rather, the general project stance has been that Policy spells out the things that are less open to debate, and bugs filed on the basis of things that aren't in Policy are more at the maintainer's discretion (assuming obvious common sense is applied). And that's what I would expect for any bugs filed about reproducible builds failing criteria more strict than those stated in Policy (such as differing build paths) until such time as project consensus builds that we want to hold all packages to that stricter standard regardless of maintainer preference. To be clear, the above discussion is intended as an explanation for this decision, not a continuation of debate. If you disagree with the above, you should probably address those objections to the Technical Committee; I feel like I have a pretty complete understanding of the issues here, and it's highly unlikely that further elaborations or rephrasings of your current arguments are going to change my mind. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>