Manuel M T Chakravarty
chak at cse.unsw.edu.au
Mon Aug 6 20:42:25 EDT 2007
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.
PS: Duncan, forward this message to cabal-devel if you think that
would be useful. It doesn't let me post directly.
More information about the Cvs-ghc