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.
Yes, after every change, even just an updated translation, I boot the OS,
> run through systemd, gdm, gnome-shelll, and everything and ensure it still
> logs in.
>
That would make sense if running the whole battery of tests after every
commit were *both* free and very fast. What I see around me, however, is
that there is never quite as much hardware as everyone would want to use,
and full test runs of the system take days. So, testing after every commit
is impractical, and when one starts with "the system fails to boot",
backtracking down to the offending commit in *the whole system* is rather a
lot of work.
Starting with the small-scale unit tests is a more efficient use of
resources: the tests are smaller and run faster, so it is actually
practical to run them after every commit (or at the very least before any
git push or other release of the component visible to other people).
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
