Pete Wyckoff <pw@xxxxxxxx> writes:
> Running tests at high parallelism on a slow machine, 5 sec is
> not enough to wait for p4d to start. Change it to 10 sec.
>
> Signed-off-by: Pete Wyckoff <pw@xxxxxxxx>
I'd rather not to see this kind of incremental micro-tweaks. The
next person who runs on an even slower box or with more excessive
parallelism compared to his machine size may complain and send a
patch to raise this to 20.
Who are we trying to help, and if you raised this to "forever", whom
would such a change be hurting? If there is something wrong with
the p4 installation, it may never come up, but an interactive user
will eventually end up seeing "waiting for p4d to start" and nothing
else in such a case, and will know to kill it with ^C. An automated
test spawned from a cron job would definitely be hurt with a timeout
of "forever", but to them, 10 seconds or 10 minutes would not make
much of practical differences (as long as you do not run such a cron
job too often).
My preference would probably be a very long default that can be
shortened (or lengthened) with an environment variable, so that a
frequent auto-builder that runs the tests every five minutes can
tune it down to 30 seconds, or something like that.
> t/lib-git-p4.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
> index 121e380..0080eae 100644
> --- a/t/lib-git-p4.sh
> +++ b/t/lib-git-p4.sh
> @@ -37,7 +37,7 @@ start_p4d() {
> p4d -q -r "$db" -p $P4DPORT &
> echo $! >"$pidfile"
> ) &&
> - for i in 1 2 3 4 5 ; do
> + for i in 1 2 3 4 5 6 7 8 9 10 ; do
> p4 info >/dev/null 2>&1 && break || true &&
> echo waiting for p4d to start &&
> sleep 1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html