[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: assumptions about the build environment.

On Thu, Sep 27, 2012 at 01:14:49PM +0100, Wookey wrote:
> In general I'm in favour of agreeing what can be relied upon and
> then only providing that in buildds. But you are quite right that for
> the purposes of buildds doing native building this improves your
> success rate by glossing over potentially-dubious checks, with little
> cost.

I guess the question here is whether we write policy on how to build a
package in support of buildd machines, or whether things are the other
way around, that is, we use buildd machines to verify packages'
compliance to policy.

If we were doing the latter, we should probably also do things like run
lintian on a package after it built, or run it through piuparts, or do
any number of other time-consuming things that would improve the quality
of our distribution overall. We are, however, not doing that, because
this is not the primary focus of the buildd network. Instead, the
primary focus of the buildd network is to build our packages for their
architecture in a timely manner.

Now I'm not saying that I'm opposed, in principle, to such testing if it
provided a net benefit; and to some extent, we are in fact already doing
that (since maintainers are encouraged to enable test suites as part of
the regular build of their packages). However, when the buildd network
is backlogged because of broken or ageing hardware, or because of
other issues not directly under the control of the buildd admins, these
admins should have the ability to cut some corners (while still
producing correct packages) so that they can cut down on the time
required when things are getting tight. To be able to do this, the
amount of things the hosts in the buildd network absolutely must do
should be a list that is shorter rather than longer.

In essense, the buildd network is not a QA resource; and while it is
okay to use it as such if buildd hosts have time to spare, I believe we
should ensure that our QA team's primary resources for archive-wide
tests should be found elsewhere, so that buildd admins have the liberty
to do what they need to do: ensure that an architecture can still be
part of the next release, by building the packages that we need to

The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

Attachment: signature.asc
Description: Digital signature

Reply to: