22.6 Logging Activity For Developers

It is not sufficient that you know how to build the releases. Others need to have access to that information as well, to the point where they can exactly replicate the steps you took and end up with bit-by-bit equal results. Should something to happen to you, whether you leave for holidays, get fed up with developers' complaints and leave for a better job, have a ski accident or die (yes, gasp, even the best software librarians have been heard to die), you need to leave behind some documentation. Developers who want to, for whatever reason, build releases themselves will also appreciate if they can find a clear description of how you go about it.

A number of the release tools make a start at producing this documentation by creating or adding to a file called ReleaseLog. This information is far from complete, so you can augment it by editing the relevant bits, by adding details about the commands you used, the details one has to pay attention to, and so forth. Of course, if you use the boot makefiles as described in the previous section, this task can become a no-brainer: the boot makefile is the documentation.

You should also redirect all output from the configure and make commands into files and leave those in the release. This is helpful not only when you have to shift through the diagnostic messages yourself, but also for tracking bugs later on and for developers to check that they are doing the right thing when they want to follow your steps. On many systems and shells you can use the following commands:
$ ../../../configure >& build.log & less -S +F build.log
$ make >>& build.log & less -S +F build.log
$ make check >>& build.log & less -S +F build.log
$ make install >>& build.log & less -S +F build.log
$ make installcheck >>& build.log & less -S +F build.log

It is probably not a good idea to use the QUIET option when you are making the releases. If you use it, it will become impossible to figure out compiler options from the build logs later on. One possibility is to use the QUIET option for the release builds that do not get any testing anyway (the bug fix releases), and not to use it with the other builds.