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

[Jan Stolarek]

Hi Austin,

I admire your talent for writing emails ;-)

As you wrote in your email I'm totally for including testsuite into GHC, because it is essentially 
part of GHC and it doesn't make sense to have a version of testsuite not corresponding to a 
version of GHC. As you pointed out the same argument can be used for other packages, but still 
there is one thing I don't like about that idea. What if an average haskeller wants to improve 
one of the libraries e.g. by adding comments or fixing a minor bug? If we have a super-repo that 
person would need to check out everything, which is discouraging. Another, separate issue here is 
that such a person needs to either register to ghc-devs or trac to send a patch. Using github 
would be helpful here, though I agree with Geoffrey about merge commits - we'd have to think of 
sth here. Also, the fact that GHC HQ is maintaining all of the mentioned packages doesn't mean 
that they need to be stored in one repo, at least not in git (this would make more sense to me 
with SVN where you can checkout a subdirectory).

Still, I strongly agree that sth should be done about current setup. I'm not a git guru so I 
cannot fully foresee what would be the consequences of turning everything into submodules, but I 
think that it cannot be worse than it is now, right?

Jan

Dnia niedziela, 9 czerwca 2013, Roman Cheplyaka napisał:
> Hi Austin,
>
> I apologize for not having read the full email yet (I'm in a hurry right
> now), but...
>
> * Austin Seipp <aseipp at pobox.com> [2013-06-09 00:23:22-0500]
>
> > --> Let's just put base and testsuite inside the GHC repository
> > directly. No submodules, no floating repos. Just put it directly
> > inside and make a super commit, I guess. GHC becomes the de facto
> > repository. And hey, why not nofib?
> >
> > I know, I know. People really want to split the maintenance burdens I
> > guess, and ideologically the Haskell community is all about clean
> > separation but, please? All of GHC HQ are the de facto maintainers of
> > this stuff anyway. And as Jan mentioned, testsuite is really *so*
> > crucial GHC should have it inline. The testsuite is perhaps the most
> > important of al
> >
> > There are other candidates for this treatment too, really. For
> > example, why is template-haskell, ghc-prim, and hpc split out? GHC is
> > the only thing that supports them. template-haskell is especially
> > super-intrusive of an extension to support, and arguably hpc as well.
> > integer-simple and integer-gmp follow the exact same story. Same with
> > hoopl and dph. They're all ours. We own them. Just put them all inside
> > GHC and be done with it. Having active fragmentation in the VCS is not
> > necessary when there need be none. These packages de-facto ship with
> > GHC and are very tied to it.
>
> I'm a strong -1 on this. As one example, we have forks of base and
> ghc-prim for Haskell suite:
>
>   https://github.com/haskell-suite/base
>   https://github.com/haskell-suite/ghc-prim
>
> which would be much more complicated if these were not independent
> repositories.
>
> But more generally, I think there's still hope that the core packages
> will be made portable — I'm referring to Joachim Breitner's work on
> splitting the base.
>
> Roman
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs