Broken head

[Duncan Coutts]

On Mon, 2007-08-06 at 19:34 +1000, Manuel M T Chakravarty wrote:

> >> ../libraries/Cabal/Distribution/System.hs:14:10:
> >>     Not in scope: `System.Info.os'
> >>
> >> This is on MacOS compiling with GHC 6.6.1.
> >>
> >> Duncan, did you run validate before pushing all these recent cabal 
> >> patches?

No. I checked that it built on it's own and passed some of it's own
regression tests.

> > We shouldn't expect Cabal developers to run GHC's validate when pushing 
> > patches.  The right thing to do is for GHC to use a branch of Cabal 
> > (subset only, so no conflicts), and only push patches to GHC's branch 
> > after a validate.
> > 
> > This entails some extra overhead to the development model.  Thoughts?
> 
> Depends on the Cabal developers, I guess.  Making sure that GHC's 
> build doesn't break might be a good regression test for Cabal.  If 
> they don't like that, using a subset-branch sounds fine (something 
> like packages/Cabal-ghc).

Problem is, checking that Cabal builds fine is no guarantee that ghc
builds with it. For example ghc uses lots of compat/Distribution/*.hs
files (that merely #include some real Cabal/Distribution/*.hs files) and
if we make slight module dep changes in Cabal it requires adding more
such files. That was the source of one recent break, though not the
System.Info.os one.

So yes, we'd have to run the full ghc validate script. If possible I'd
rather avoid making all Cabal contributers do that since we're trying to
make Cabal development more assessable.

> However, this raises the general question of GHC's core packages. 
> Cabal might be a special case, but generally validate is only 
> moderately useful (as we just saw) unless the obligation to run it 
> applies to all core packages of GHC.  (I don't think it makes sense 
> to use subset-branches for all core packages.)

But even if we did run validate, sometimes we do have to make breaking
changes to the Cabal interface. Especially in this development cycle
we've been trying to get all the breaking changes through so we can 

I'm not sure it's ok to ask Cabal contributers to not only run validate
after making api changes, but also to fix ghc and all core packages that
break due to that. It's too heavy. IMHO, our main problem in Cabal is
lack of development progress rather than too many changes too quickly.

So what to do? One thing I suggested previously was a way of making
temporary branches and feeding them to the build bots. So we could push
these kinds of changes to such a branch and see what the fallout is
without breaking the main tree. It'd need some automation to make it
manageable I suspect. Perhaps it should be something where the core
branch pulls upstream changes into the temp branch and runs them through
the build bots, using the last buildable ghc, then if it builds it gets
pulled through to the branches that ghc uses. So it'd still be automatic
in the usual non-breaking case. In the breaking case we get an email and
the changes do not propagate into the ghc head branches.

Duncan