Roman, Manuel, (ccing cvs-ghc).
Background for others. Roman is working on
- making package 'vector' into a new boot package that GHC depends on
- removing lots of code from the dph library
Result: the 'dph' package depends on 'vector' rather than duplicating it.
We would like to get this change into the release, so that the branch and the
HEAD do not differ too much, and patches can transfer over easily.
Roman: our usual plan is to have a "lagging Darcs repo" in
http://darcs.haskell.org/packages,
which is the copy of 'vector' (or 'bytestring' etc) that GHC uses. Not a
tarball. The rule is
- we do not push to these lagging repos
- we update the lagging repo from the master at convenient intervals
This must makes sure that GHC builders are not exposed to random increments in
the master repo for an independently maintained library.
See http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries
So, in the short term, you could make d.h.o/pacakges/vector be *more* up to
date than the released 'vector', I suppose.
Simon
| -----Original Message-----
| From: Manuel M T Chakravarty [mailto:[email protected]]
| Sent: 15 September 2010 15:14
| To: Leshchinskiy, Roman
| Cc: Simon Peyton-Jones; Roman Leshchinskiy; Ben Lippmeier
| Subject: Re: DPH & vector
|
| Leshchinskiy, Roman:
| >> I don't quite understand why we need to have everything
| >> sorted out with the public vector distribution. Why don't we
| >> do the following?
| >>
| >> (1) Put a fork of the vector darcs repo somewhere on
| >> darcs.haskell.org.
| >> (2) Tar that forked repo up to get us a tarball.
| >> (3) Push your changes to package dph into the tree and put
| >> the tarball from (2) into the ghc repo.
| >
| > I thought that the release candidate should only contain those packages
| > that are intended to be shipped with the final release. Note that the
| > "fork" can't even be called vector such as not to conflict with the
| > actual vector package. Are you saying it would be ok to replace this
| > later in the release cycle? If so, then why wouldn't it be ok to just
| > add vector then? Not that I want to, I'm just asking.
|
| [Disclaimer: This is my personal opinion and I haven't checked with GHC HQ.]
|
| The release candidate should be as close to what we want to ship as possible.
| A tarball that is going to change a little later on (and already uses the
| final build setup) is much closer than having the old DPH package without
| vector. In other words, I hope that GHC HQ will let us change the tarball a
| little later on, but they are surely not going to let us merge your work
| after the release process started. (In short, it is not about whether we can
| change anything after the release candidate. It is about how big the changes
| can be.)
|
| > FWIW, my contingency plan is to add a dph-vector subdir to the dph repo
| > and have our copy of vector live there without messing around with
| > tarballs at all. That's the setup I'm using at the moment in my local
| > tree. If all else fails, I can do this early next week without affecting
| > any other part of GHC.
|
| That's a good idea, too, but it means that the build system won't know about
| the vector tarball yet. For the release process, I believe it is an
| advantage if the build process is as close to the final version as possible.
|
| > In any case, as I said, my todo list says "DPH" for this weekend. The
| > release candidate is only coming out next week so I was under the
| > impression that I would have the weekend to finish things. Is that not
| > the case?
|
| Personally, I think, finishing this over the weekend is fine. (Again, this
| is just my opinion.) If you are sure that you are going to be able to get it
| all done this weekend, that's fine by me. My proposal was just aimed at
| cutting down on the amount of work that you need to do to get everything in,
| so that we can be sure it gets done in time (ie, to have less variables that
| can hold the process up again in unexpected ways).
|
| Manuel
|
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
