2014-02-26 22:53 GMT+01:00 Richard W.M. Jones <rjo...@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 <walt...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
