Head broken again

[Simon Marlow]

Roman Leshchinskiy wrote:

> To be entirely honest, I don't see why I can't have both most of the 
> time (I wouldn't mind too much if head was broken *occasionally*). I 
> think simply testing potentially destabilising patches on multiple 
> architectures before submitting/pushing them and clearly stating what 
> has/hasn't been tested when submitting would go a long way towards that. 
> For projects like the dynamic linking stuff, where testing probably 
> happens gradually, a branch would perhaps be more appropriate. It does 
> work (not perfectly, but definitely better) for other projects. Perhaps 
> ghc has reached a threshold in the number of developers where a more 
> controlled patch submission/application process is required.

As you know, so far we've been resistant to adding significant amounts of 
"process" to modifying the HEAD, because it'll necessarily slow down 
development.  Instead, we've added lots of other measures:

   - the STABLE branch, only tested bugfixes get merged

   - Buildbot

   - The "FIX BUILD" notation for patch naming

   - The "known buildable" repositories (soon...)

   - We're going to make Buildbot send messages to #ghc when builds fail,
     this should mean we can be more responsive.

I've just added a "fast" buildbot build on our x86_64 machine that can be 
started manually, I just tried it and it took 41 minutes (compared to 2+ hours 
on Windows for the same build!).

Personally, I think requiring a complete bootstrap/testsuite on two platforms 
for every patch is still prohibitively expensive: up to 2 hours for each build 
plus the time and effort to set them up - that's if you even have access to 2 
different platforms.  If the developer doesn't have 2 platforms, then we have to 
do the testing.  What's the easiest way to get the testing done?  Push the 
patch, and let buildbot do it.  This is why I think the staging/tested 
repositories suit our needs better.

This is just MHO of course - we're happy to discuss better practices here, and 
we can certainly try different strategies to see what works better.

Cheers,
	Simon