Duncan Coutts wrote,
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.
An automated system would be cool, but it'd require some effort to
set up. In the meantime, we should probably go with SimonM's
proposal and just make GHC use a subset-branch of the main Cabal
repo. Pulling changes over into GHC's Cabal branch would be a
manual process, which would involve running validate. Especially,
if, as you wrote, you guys are currently looking at breaking
changes, that would be fairly urgent. I'd rather not have another
round of the GHC build breaking every week.
Manuel
PS: Duncan, forward this message to cabal-devel if you think that
would be useful. It doesn't let me post directly.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
