duncan.coutts: > In message <[EMAIL PROTECTED]> Don Stewart > <[EMAIL PROTECTED]> 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 _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
