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.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
