On 06/06/2011 23:28, David Waern wrote:
2011/6/6 Ian Lynagh<[email protected]>:
On Mon, Jun 06, 2011 at 05:45:19PM +0000, David Waern wrote:
So I'd like to ask you if you'd be OK with this plan? You would all
need kill your local haddock2 clones and create new clones.
If we do this, let's do it at the same time as recreating the binary
repository.
To stop the two repos from diverging again we could either kill the
darcs repo or forbid comitting directly to the git repo.
In the darcs days, the two were intentionally diverging as the upstream
repo was supporting the last stable GHC release, whereas the GHC HEAD
repo needed to work with HEAD. How are we going to handle that now?
Now that we're using git I don't feel brave enough to continue with
the old scheme, where I tried to make things convenient for both
Haddock and GHC developers.
My proposal (which is the same as Ian has been advocating before):
* ditch the darcs repo and just make the GHC HEAD repo the new upstream
* upstream only needs to work with GHC HEAD
* stable branch is created when GHC is branched, as before
* haddock developers have to do new development with GHC HEAD
* haddock developers have to validate before pushing changes
* GHC developers can continue as before
* major releases would probably become tied to major GHC releases
This is definitely simpler. The downside is that things become less
convenient for Haddock developers and I fear that we'll get fewer
contributions. However I'm still in favor of this proposal because the
alternatives I've thought about feel too complicated.
I think you need a separate development branch. The branches would
therefore be:
- stable: the one we ship with GHC releases
- development: works with the latest GHC release, but has new
Haddock development (fixes from stable merge in here)
- master: works with GHC HEAD, merges from development
Then I think everyone is happy. Haddock development happens on the
development branch and doesn't need GHC HEAD, we can keep the master
branch working with GHC HEAD, and we merge from development into master
from time to time.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
