Proposal: better library management ideas (was: how to checkout proper submodules)
jan.stolarek at p.lodz.pl
Sun Jun 9 18:59:31 CEST 2013
> You can be honest and just call them what they are: horribly written
Actually, I was thinking that instead of posting to the list you might consider publishing your
emails as papers on workshops or symposia ;)
> for high-traffic repositories, some of the concerns are disconcerning.
But the high-traffic repositories (base, testsuite) are already submodules, right? For me the
major problem of the current setup is that we cannot use one of the most important features of a
VCS, i.e. going back in time. The only solutions to this problem that I am aware of are folding
or turning into submodules all libraries that GHC depends on.
I just had this moment of enlightment that the question of including a repo as a submodule (or
folding it into GHC tree) is not a matter of traffic, but a matter of that library's
implementation. If it uses GHC-specific API then it goes in, because it is tightly-coupled. If it
is implemented in standard Haskell then it can stay out, because changes to compiler should not
affect it. This is pretty simple criterium to identify libraries that we should be concerned with
(perhaps this is obvious, but it only occured to me now). So a high-traffic repo that does not
depend on non-standard features of GHC could still be kept as an in-tree repo, without affecting
the ability to go back in time.
More information about the ghc-devs