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 build. -- 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