FAQ
Crazy proposal: Run the compiler and runtime tests before the
standard library tests in all.bash

Rationale:

If the compiler is broken, the standard library tests give us less
useful information than the compiler tests; the stdlib tests are
very likely to fail, and we won't get to the compiler tests to see
more useful failures.

In other words, the compiler tests and the compiler tests are more
fundamental than the standard library tests, so it makes sense (to
me) to run them before the standard library tests.

Counter arguments:

Most people work on the standard library, so if they break something,
it will take longer for all.bash to get to the failure.

To that I respond that people can use go test std before running
all.bash. This proposal is mostly about the builders. Sometimes the
compiler is broken, but we don't see exactly how because the compiler
tests don't run because the standard library tests failed.

Alternatives to this proposal:

Run compiler tests even if the standard library tests fail. Don't
stop, just keep going (in fact we used to do that for Plan 9 for a
while).

--
Aram Hăvărneanu

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Russ Cox at Apr 2, 2015 at 11:21 pm
    No. The default is right for the vast majority of developers. If you need
    to debug you can always run the tests in that directory yourself.

    Believe me, I understand how much better this would make it when the
    compiler is broken. But the majority of the time the compiler is not
    broken. You're optimizing the wrong case.

    Russ

    On Thu, Apr 2, 2015 at 6:31 PM, Aram Hăvărneanu wrote:

    Crazy proposal: Run the compiler and runtime tests before the
    standard library tests in all.bash

    Rationale:

    If the compiler is broken, the standard library tests give us less
    useful information than the compiler tests; the stdlib tests are
    very likely to fail, and we won't get to the compiler tests to see
    more useful failures.

    In other words, the compiler tests and the compiler tests are more
    fundamental than the standard library tests, so it makes sense (to
    me) to run them before the standard library tests.

    Counter arguments:

    Most people work on the standard library, so if they break something,
    it will take longer for all.bash to get to the failure.

    To that I respond that people can use go test std before running
    all.bash. This proposal is mostly about the builders. Sometimes the
    compiler is broken, but we don't see exactly how because the compiler
    tests don't run because the standard library tests failed.

    Alternatives to this proposal:

    Run compiler tests even if the standard library tests fail. Don't
    stop, just keep going (in fact we used to do that for Plan 9 for a
    while).

    --
    Aram Hăvărneanu

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at Apr 4, 2015 at 10:07 am
    But I can't run the ppc64 or the arm tests, because I don't have a
    ppc64 or an arm. I have to rely on the all.bash ran by the builders.

    --
    Aram Hăvărneanu

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Apr 4, 2015 at 11:00 am
    We'll get that fixed soon. Both adding ppc64/arm64 to trybots and also test
    sharding so we'll run all tests, mostly in parallel when hardware is
    available.

    David Crawshaw and I have been making progress lately.
    On Apr 4, 2015 12:07 PM, "Aram Hăvărneanu" wrote:

    But I can't run the ppc64 or the arm tests, because I don't have a
    ppc64 or an arm. I have to rely on the all.bash ran by the builders.

    --
    Aram Hăvărneanu

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Apr 4, 2015 at 9:06 pm
    I made a proposal at #10336 to add a flag for trybot to keep
    running tests in case of failures. I think that will solve the
    problem.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 2, '15 at 10:31p
activeApr 4, '15 at 9:06p
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase