2014-02-26 22:53 GMT+01:00 Richard W.M. Jones <rjones@redhat.com>:

On Wed, Feb 26, 2014 at 04:58:43PM +0100, Miloslav Trmač wrote:
> 2014-02-26 14:11 GMT+01:00 Colin Walters <walters@verbum.org>:
>
> > During making glib changes you should run glib unit tests to have some
> > basic level of assurance you didn't introduce regressions or unwanted
> > changes.
> >
> > The *very first* test I run is "does the OS still boot"? That's called
> > "smoketest" for me, and it only takes a few minutes.
> >
>
> That seems to be optimizing for bugs that break the boot, when bugs that
> occur in less-frequently used parts of the system are far more common; a
> lot of software is not used, or not critical, in the boot path.

But bugs which break the boot prevent you from testing everything else.

Only if I would reboot boot my primary workstation into the new untested software, which I don't do.

Sure, there's the kernel and the graphics drivers and the like which need physical hardware and booting, but these are the rare exceptions within the package universe.

As for the case that "I need to reboot so that the gtk2 test suite catches glib2 bugs", most of these cases are missing tests in glib2. Yes, the final reboot and re-running all individual test suites in the new environment might be useful, if there is time and capacity to do such a test, but it shouldn't be the primary execution mode of the tests; it's too costly and unfocused, and too far removed from the programmer in the think/edit/build/test cycle.

Mirek