bytestring

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Fri Oct 12 11:55:38 EDT 2007


In message <20071012030223.GA28363 at scytale.galois.com> Don Stewart
<dons at galois.com> writes:
> simonmarhaskell:
> > Don Stewart wrote:
> > >dons:
> > >>simonpj:
> > >>>   In bytestring package, Data.Char8 doesn't even get past the parser. 
> > >>>   What's going on with bytestring?
> > >>>
> > >>Looks like the last patch added a ',' to the end of a line, which was
> > >>silently accepted by 6.6.1 which Duncan uses, but failed with the head
> > >>(which I use).
> > >>
> > >>Patch applied.
> > >
> > >Raises an interesting issue that library maintainers need to check
> > >against 2 or 3 different ghc versions for each patch. Hmm.
> > 
> > We don't want to impose such a burdensome regime - the rule is, if you've 
> > run validate then you're off the hook.  For the Cabal folks we've even 
> > forked Cabal so that the developers don't have to validate at all, and we 
> > could consider doing that for other libraries too.
> > 
> 
> We forked bytestring during the hackathon too. So the head branch on
> darcs.haskell.org is now the de facto stable branch, since GHC uses it.

If we're doing this we should be consistent about it. ie where the head should
go, where the other branches should go. Here's Cabal's layout at the moment:

Cabal HEAD: d.h.o/cabal
ghc HEAD branch of Cabal: d.h.o/packages/Cabal
ghc-6.8 branch of Cabal:  d.h.o/ghc-6.8/packages/Cabal

but for bytestring we appear to be going in a different direction:

HEAD: code.h.o/bytestring
ghc:     d.h.o/bytestring
ghc-6.8: d.h.o/ghc-6.8/packages/bytestring

I don't really mind where they go exactly so long as it's consistent between
packages and clear to people. People have already been fairly confused about the
different Cabal branches.

It's also related to what the darcs.h.o vs code.h.o split should be. Should we
aim for only core packages on darcs.h.o? or only ghc, and have the head branches
of projects hosted on code.h.o or what?

We're currently being inconsistent and confusing.

Duncan



More information about the Cvs-ghc mailing list