A (not so) small insight from the g4u release process
(OK, I'm bored sitting & waiting here, so let's fill the void...)
Quite some time ago, at around the times of g4u 1.14/1.15
(see the g4u history), I came to the decision that just typing
"make" is nice for releasing simple software, but with
increasing complexity, some more formal testing before release
is nice to have to find those trivial errors that DO sneak in.
As a result, I fired my previous quality assurance department and
made up my own g4u release plan, which is roughly:
"RUN THIS LIST OF TESTS BEFORE THE RELEASE".
Simple, eh? It saved my butt a few times since then.
Now what highly complex list of commands do I run before a release?
Here's the list (keep in mind that g4u exists to copy partitions
and whole disks locally and via network):
% cp harddisk.template harddisk0
% cp harddisk.template harddisk1
% qemu -cdrom g4u.iso -hda harddisk0 -hdb harddisk1
Commands to run:
g4u> dmesg
g4u> ls
g4u> ifconfig -a
g4u> disks
g4u> parts wd0
g4u> parts wd1
g4u> copydisk wd0 wd1
g4u> GZIP=1 uploaddisk upload@10.0.0.3 rwd1d.gz wd1
g4u> slurpdisk upload@10.0.0.3 rwd1d.gz wd0
g4u> uploadpart upload@10.0.0.3 rwd0a.gz wd0a
g4u> slurppart upload@10.0.0.3 rwd0a.gz wd1a
g4u> copypart wd0e wd0f
g4u> copypart wd0f wd0e
Not very complex, isn't it? That's actually the whole point:
have some _simple_ steps that test _basic_ functionality,
and make sure that's not broken. And it works, and makes
me (and hopefully all the g4u users :-) happy.
(Seeing something like this in NetBSD would be a longstanding
dream of mine... the list would start with "Grab a common configuration
of $arch, put the native operating system on it and then install
NetBSD on it" and "get X going")
While talking about being happy (I'm bored while waiting for the
above regression testing commands right now :-): I think
I've found while progress(1) seems to act funny, as documented
in NetBSD's
PR 33207. (And that supposed fix is actually the reason for
doing another round of regression tests :-):
stat(2) on a pipe returns some "funny" results, which
seems to confuse progress(1):
miyu% perl -e 'print "x" x 1' | stat -f %z
1
miyu% perl -e 'print "x" x 10' | stat -f %z
0
miyu% perl -e 'print "x" x 10' | stat -f %z
10
miyu% perl -e 'print "x" x 100' | stat -f %z
100
miyu% perl -e 'print "x" x 100' | stat -f %z
100
miyu% perl -e 'print "x" x 100' | stat -f %z
100
miyu% perl -e 'print "x" x 100' | stat -f %z
0
I'll leave it for someone else to debug _that_...
[Tags: g4u]
|
