Merge lp:~vila/bzr/837926-log-make-check into lp:bzr/2.0

+ echo `date` selftest [ascii] starts 1>&2

for portability across shells, i think you should quote the string (specifically the square brackets.)

if that's enough to help with this, it's ok with me.

i would think about changing it to run ./bzr underneath 'time'.

superseded by https://code.launchpad.net/~vila/bzr/837926-log-make-check-trunk/+merge/73500 targeted to trunk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/31/2011 11:09 AM, Vincent Ladeuil wrote:
> Vincent Ladeuil has proposed merging
> lp:~vila/bzr/837926-log-make-check into lp:bzr/2.0.
>
> Requested reviews: bzr-core (bzr-core)
>
> For more details, see:
> https://code.launchpad.net/~vila/bzr/837926-log-make-check/+merge/73492
>
>
>
I'd like to have more precise timings of our landings on pqm.
>
> I've asked our losas for the log files and learned they were
> already mirrored on chinstrap.
>
> But their content still don't give us enough data: at best we get
> the end date which is only useful if several jobs have been
> queued.
>
> This patch add some echo statements redirected to stderr so they
> end up in the log file.
>
> The plan is to apply this patch to all our branches there (2.0 ->
> trunk) with the nedeed tweaks (the makefile have evolved for
> almost all series so merging up will conflict).

So we don't keep the selftest output itself? (when using --subunit
we record the absolute times as it runs.) Which means failing tests
give you pretty accurate timing, which is one of the reasons I'm doing
it. (That and because it allows me to run things without adding them
to a real branch.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5eBGsACgkQJdeBCYSNAANG9ACglHQcxV5ageGNSU9erSr564ie
hx8AnRfdSD79b4oBsTDP0DzUAlpp5+XE
=Z/Wa
-----END PGP SIGNATURE-----

>>>>> John Arbash Meinel <email address hidden> writes:

<snip/>

    > So we don't keep the selftest output itself?

This doesn't interfere with the existing behavior to avoid fallouts.

    > (when using --subunit we record the absolute times as it runs.)
    > Which means failing tests give you pretty accurate timing, which
    > is one of the reasons I'm doing it. (That and because it allows me
    > to run things without adding them to a real branch.)

Right, I want to keep that behavior.

But we don't get the subunit output at all for successful landings nor
do we get subunit outputs for others submissions. So I went a different
route.