Proposal: better library management ideas (was: how to checkout proper submodules)

[Jan Stolarek]

> You can be honest and just call them what they are: horribly written
> novellas.
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.

Jan