Head broken again

[Simon Peyton-Jones]

Manuel

| I think its a matter of scalability.  The "testing by pushing to head" approach
| that you seem to advocate worked well enough when few people were hacking GHC.
| However, it seems that the number of GHC developers has been growing quite a bit
| in recent times

I agree completely. It's a nice problem to have (lots of developers), but it is a real problem, and I know you are fed up with wasting time.

In my mind I see, in order of increasing cost:

        A) The status quo
        B) Last good snapshot
        C) Something more elaborate

Because the cost goes up, it might be worth trying (B) before (C), and we have not tried it yet. It's clearly better than what we have been working with for the last 10 yrs, but it's still cheap.  Perhaps it'll fix 90% of the pain for 10% of the cost.

If that doesn't work, then perhaps something more elaborate will be needed.

But to be concrete, what specifically do you recommend for (C)?  A self-discipline on developers that they don't check in changes until they have tested them?  I'm sure they already try not to (e.g. I run the typechecker test suite before checking in a typechecker patch), but partial tests are by definition not comprehensive.  An automated system to which they submit patches that are then auto-tested and rejected on failure?  That would be good, but it sounds quite complicated to set up.  Can you be more concrete about your proposal?

| more people waste their time with a broken head.  Even if we have the
| "guaranteed to be buildable" snapshots, there is an overhead in trying the head,
| discovering it is broken, and moving to a snapshot.

What I'm missing is this: why not *always* pull from the snapshot?  By going for the bleeding edge you by definition expose yourself to instability, (C) included.  If some vital fix is needed specifically for the NDP branch, maybe whoever makes that patch (eg me) should do it on your branch?

In short,
        are you convinced that (B) is unworkable?
        what do you have in mind for (C)?

Simon

PS: Even with (C), build-system changes are particularly difficult to test, so they are always going to be painful.  I hope that our build system is now settling down after a period of particularly rapid change, so I hope the last few months are uncharacteristic.