Signed-off-by: Francois Gouget fgouget@free.fr --- testbot/lib/WineTestBot/Activity.pm | 2 +- testbot/lib/WineTestBot/Engine/Scheduler.pm | 2 +- testbot/lib/WineTestBot/PatchUtils.pm | 2 +- testbot/lib/WineTestBot/Steps.pm | 2 +- testbot/lib/WineTestBot/Tasks.pm | 2 +- testbot/web/Activity.pl | 2 +- testbot/web/Munin.pl | 2 +- testbot/web/Stats.pl | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/testbot/lib/WineTestBot/Activity.pm b/testbot/lib/WineTestBot/Activity.pm index eba45a039e..2a1e21f0ba 100644 --- a/testbot/lib/WineTestBot/Activity.pm +++ b/testbot/lib/WineTestBot/Activity.pm @@ -68,7 +68,7 @@ for the specified timestamp. Entries have the following structure: vm => <VMObject>, status => <VMStatus>, value => <RecordValue>, - task => <TaskObjectIfAppopriate>, + task => <TaskObjectIfAppropriate>, start => <StartTimestamp>, end => <EndTimestamp>, rows => <NbRows>, diff --git a/testbot/lib/WineTestBot/Engine/Scheduler.pm b/testbot/lib/WineTestBot/Engine/Scheduler.pm index c28e143310..800d136835 100644 --- a/testbot/lib/WineTestBot/Engine/Scheduler.pm +++ b/testbot/lib/WineTestBot/Engine/Scheduler.pm @@ -884,7 +884,7 @@ sub _RevertVMs($$) # Note that during regular operation we get dirty VMs before they are # assigned a process to shut them down. This makes it possible to pick # the best future VM while we still know which VM is hot. - # In constrast on startup the dirty VMs all have processes checking their + # In contrast on startup the dirty VMs all have processes checking their # status, hence the dirtychild check to ensure we are not prevented from # preparing the best VM (e.g. build): it delays preparing the future VMs # until either there are no dirty VM or a VM got prepared for a task diff --git a/testbot/lib/WineTestBot/PatchUtils.pm b/testbot/lib/WineTestBot/PatchUtils.pm index 44b3f97cca..df31a095a7 100644 --- a/testbot/lib/WineTestBot/PatchUtils.pm +++ b/testbot/lib/WineTestBot/PatchUtils.pm @@ -373,7 +373,7 @@ sub GetPatchImpacts($) } elsif ($Line eq LastPartSeparator()) { - # All the diffs so far belongs to previous parts of this patchset. + # All the diffs so far belong to previous parts of this patchset. # But: # - Only the last part must be taken into account to determine if a # rebuild and testing is needed. diff --git a/testbot/lib/WineTestBot/Steps.pm b/testbot/lib/WineTestBot/Steps.pm index c9ce3439b3..094337569d 100644 --- a/testbot/lib/WineTestBot/Steps.pm +++ b/testbot/lib/WineTestBot/Steps.pm @@ -30,7 +30,7 @@ A Job is composed of one or more Steps that each perform one operation. A Step is in turn composed of one WineTestBot::Task object for each VM that the Step should be run on.
-A Step's lifecyle is as follows: +A Step's lifecycle is as follows: =over
=item * diff --git a/testbot/lib/WineTestBot/Tasks.pm b/testbot/lib/WineTestBot/Tasks.pm index 5a79ff91d1..141fee07b6 100644 --- a/testbot/lib/WineTestBot/Tasks.pm +++ b/testbot/lib/WineTestBot/Tasks.pm @@ -31,7 +31,7 @@ performing that Step in a WineTestBot::VM virtual machine. For instance a Step responsible for running a given test would have one Task object for each virtual machine that the test must be performed in.
-A Task's lifecyle is as follows: +A Task's lifecycle is as follows: =over
=item * diff --git a/testbot/web/Activity.pl b/testbot/web/Activity.pl index d616a7c1db..9444779433 100644 --- a/testbot/web/Activity.pl +++ b/testbot/web/Activity.pl @@ -290,7 +290,7 @@ sub GenerateFooter($) print "<span class='Record-running'>running</span> a task (in which case it links to it),<br>\n"; print "<span class='Record-dirty'>dirty</span> while the server is powering off the VM after a task or while it assesses its state on startup.</p>\n";
- print "<p>If no time is indicated then the VM remained in that state for less than 2 seconds. The tasks column indicates the number of runnable / queued tasks before that scheduling round. If any task needs to run on a maintenance, retired or deleted VM is is shown as +N. A long horizontal bar indicates the TestBot server was restarted. </p>\n"; + print "<p>If no time is indicated then the VM remained in that state for less than 2 seconds. The tasks column indicates the number of runnable / queued tasks before that scheduling round. If any task needs to run on a maintenance, retired or deleted VM it is shown as +N. A long horizontal bar indicates the TestBot server was restarted. </p>\n"; print "<p>This <span class='Record Record-running Record-timeout'>border</span> indicates that the task timed out,<br>\n"; print "this <span class='Record Record-running Record-error'>border</span> denotes a transient (network?) error so the task will be re-run,<br>\n"; print "and this <span class='Record Record-running Record-boterror'>border</span> indicates a TestBot error.<br>\n"; diff --git a/testbot/web/Munin.pl b/testbot/web/Munin.pl index 35160a159a..c2464d055c 100644 --- a/testbot/web/Munin.pl +++ b/testbot/web/Munin.pl @@ -82,7 +82,7 @@ happened in the past 5 minutes. However we have to report on infrequent events: - New jobs arrive infrequently: around one per hour currently, and it is not rare for two of them to arrive at the same time. If we were to naively extrapolate 1 new job in the past 5 minutes as a rate of 12 jobs per hour - we'd get a graph with exagerated swings. But note that things would converge + we'd get a graph with exaggerated swings. But note that things would converge on a meaningful value as Munin averages things out for the monthly or yearly graphs. - We could instead record when the last job arrived and derive a rate by diff --git a/testbot/web/Stats.pl b/testbot/web/Stats.pl index f453891452..4a70cb0e00 100644 --- a/testbot/web/Stats.pl +++ b/testbot/web/Stats.pl @@ -426,7 +426,7 @@ sub GenerateFooter($) print "<p>The <b>Job rate</b> and <b>Task rate</b> show the average hourly rate at which jobs / tasks are submitted to the TestBot. The <b>Revert rate</b> shows how many reverts have been done per hour to run those tasks. Note that the job and task rates provide a first approximation upper limit on the average time a job or task can take to complete.</p>\n"; print "<p>The <b>Busy time</b> indicates how long the TestBot had at least one pending task and the <b>Busy %</b> shows how much of the wall clock time this represents. Note that the busy percentage and average <b>Job completion</b> times can be optimized by balancing the load on the different VM hosts.</p>\n"; print "<p>The average and maximum time statistics show how long the VMs spend in each state of their lifecycle. A VM starts in the powered off or dirty state. It is then <b>reverted</b> to a clean state with the right configuration for the tests. Then it goes into the <b>sleep</b> state during which it gets ready to run the tests. Depending on the VM configuration this may be immediate or may require booting the VM first. Then it goes into the <b>run</b> state while the tests are being uploaded, run, and the results retrieved. This means the test itself takes less time to run than indicated in this statistic. Also note that the <b>WineTest</b> and <b>Wine update</b> tasks are tallied separately because they take much longer than regular tasks. Once the tests complete the VM is marked <b>dirty</b> while it waits for the TestBot to decide whether to power it off, or immediately revert it for the next task.</p>\n"; - print "<p>The errors section shows how many <b>Timeouts</b> occurred, that is how many tasks failed to complete within the alloted time; how many failed due to a <b>TestBot error</b>; and how many had to be rerun due to a <b>Transient error</b> such as a network connection issue.</p>\n"; + print "<p>The errors section shows how many <b>Timeouts</b> occurred, that is how many tasks failed to complete within the allotted time; how many failed due to a <b>TestBot error</b>; and how many had to be rerun due to a <b>Transient error</b> such as a network connection issue.</p>\n";
print "</td></tr></tbody>\n"; print "</tbody></table></div>\n";