Containers -- how to synchronize development and lagging repo
Hi GHC HQ, with the new library submission process, I think we should have development repo for containers (maybe on github?). Is there any standard way of dealing with lagging repos? I am not sure if updating the lagging repo and releasing cabal packages is responsibility of GHC HQ of the maintainers. With the new library process, there will probably be more people affected by this issue. BTW, we can also do the development on different branch of the repo, or the lagging repo can be a different branch. But it sounds a bit tricky... Cheers, Milan
Hello Milan, We currently have a lagging repository system setup for Hoopl described here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen maybe it is applicable for the containers process? It does, however, predate the switch to Git, and it's possible that just using multiple branches might also bean option. Edward Excerpts from Milan Straka's message of Fri Jun 10 08:11:59 -0400 2011:
Hi GHC HQ,
with the new library submission process, I think we should have development repo for containers (maybe on github?).
Is there any standard way of dealing with lagging repos? I am not sure if updating the lagging repo and releasing cabal packages is responsibility of GHC HQ of the maintainers. With the new library process, there will probably be more people affected by this issue.
BTW, we can also do the development on different branch of the repo, or the lagging repo can be a different branch. But it sounds a bit tricky...
Cheers, Milan
Hi Edward and all,
Hello Milan,
We currently have a lagging repository system setup for Hoopl described here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen maybe it is applicable for the containers process? It does, however, predate the switch to Git, and it's possible that just using multiple branches might also bean option.
so it seems it is the responsibility of the maintainers to push to the lagging repo and do the GHC validation? Can we also release the cabal packages? Should the numbering of the package somehow correspond to the GHC releases? Cheers, Milan
Edward
Excerpts from Milan Straka's message of Fri Jun 10 08:11:59 -0400 2011:
Hi GHC HQ,
with the new library submission process, I think we should have development repo for containers (maybe on github?).
Is there any standard way of dealing with lagging repos? I am not sure if updating the lagging repo and releasing cabal packages is responsibility of GHC HQ of the maintainers. With the new library process, there will probably be more people affected by this issue.
BTW, we can also do the development on different branch of the repo, or the lagging repo can be a different branch. But it sounds a bit tricky...
Cheers, Milan
On Fri, Jun 10, 2011 at 2:11 PM, Milan Straka
Hi GHC HQ,
with the new library submission process, I think we should have development repo for containers (maybe on github?).
+1 for Github, in the "haskell" organization that Johan set up.
If the submission process is truly becoming more sane (i.e. you guys
get a pull request and apply it), I may have some patches coming.
G
--
Gregory Collins
Hi Milan, On Fri, Jun 10, 2011 at 02:11:59PM +0200, Milan Straka wrote:
Is there any standard way of dealing with lagging repos?
I've now set up a nightly cronjob to send mail if there are pending patches to pull, in which case I shall pull them and try validating. Thanks Ian
participants (5)
-
Edward Z. Yang -
Gregory Collins -
Ian Lynagh -
Kazu Yamamoto -
Milan Straka