Bill Allombert <ballo...@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. But I'm taking this position for a large number of reasons, of which consensus at DebConf is only one. > 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). 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. I am not at all trying to rule out constructive suggestions to make the language better, either now or in subsequent revisions of Policy. I think what we've got is pretty good, and I am comfortable with putting it into Policy now, but concrete wording proposals with justification would be welcome. Like everything else in Policy, we can always improve how we describe our project-wide baseline. It's not normally Policy's role to offer detailed advice on how to meet a particular requirement. For example, Policy mentions debhelper in a few footnotes but doesn't document how to use it to create compliant packages in general. That's not its purpose; usually that sort of documentation can be better-maintained by other teams, such as the reproducible builds team. The definition in the current proposal is intentionally weaker (in the sense that fewer packages would fail it) than what current reproducible build testing is doing in a few places (such as with environment variables) because it takes a conservative stance to set a baseline and it errs on the side of a clear and simple problem statement. It's possible that we'll want to make it more complex in the future, but I think with environment variables we should first have a discussion (Ximin and I started that; I probably should move it off this thread) because I'm not sure that's the best approach. In the meantime, this achieves the goal of declaring a baseline that Debian packages should be reproducible under controlled and simple-to-state circumstances, which is something for which I'm quite sure we have general project consensus. If you believe it is premature to specify this in Policy entirely, I strongly disagree, and am not persuadable on that point. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
