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