Subject: Re: NetBSD SQA process
To: None <tech-kern@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-kern
Date: 04/20/1999 02:55:24
[ On , April 19, 1999 at 18:03:31 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: NetBSD SQA process
>
> In my opinion, the right 'first' place to improve 'quality' of NetBSD
> is making sure that -current builds all the time, and making sure that
> people who break it catch heat for it.  (I.e. change the age-old
> belief that not compiling or working for weeks at a time is 'ok'.)

I think this is not a good idea, at least for the moment -- I doubt many
developers can even attempt to test that -current will build on all
supported target systems.  Giving a developer hassles and negative
feedback just because they broke something they can't even test is not
someting I can condone.

> A tool like tinderbox could be great for this, but you'd need to fix the
> build system so that you can really build bits from scratch in one go
> without privs (so that the builds could repeat infinitely without
> bootstrapping issues).

Well, yes, tinderbox *might* make such a rule more "acceptable", but
indeed what's really necessary is a full cross-compilation system and
totally self-supporting build system (as I outlined a little while ago,
based on your and other's previous ideas).  Building "bits" from scratch
is not sufficient -- they must be built on a cross-compilation system as
if they had been built on the target system -- and the final result must
be byte-for-byte identical (sans timestamps, etc., of course).

Of course since this is a full operating system, not just a user-level
application, there's also the issue of basic kernel fuctionality -- and
testing this really does require a regression testing harness that'll
support autonomous control of a remote hardware test platform.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>