Bug#844431: Revised patch: Oppose

[Russ Allbery]

Bill Allombert <ballombe at 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 (rra at debian.org)               <http://www.eyrie.org/~eagle/>