bytestring

[Don Stewart]

duncan.coutts:
> 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.

I like code.haskell.org, because we get very fine grained permissions on
projects. I'd leave darcs.haskell.org for just the compilers and core
libs only. 

-- Don