how to checkout proper submodules

Wed Jun 5 11:10:07 CEST 2013

On 5 June 2013 01:43, Manuel M T Chakravarty <chak at cse.unsw.edu.au> wrote:

> I agree with Austin and Johan. It's a bizarre setup. Submodules have their
> pain points (which we already have to deal with), but the ability to
> properly snapshot and branch the whole tree would be a serious benefit IMO.
>
> Manuel
>
> PS: While we are at it, why don't we just have the main repos on GitHub
> and use forks and pull requests like the rest of the world? (Using Git, but
> not GitHub's superb infrastructure, seems like a terrible waste to me.)
>

I'd be all for this. We partially use the GitHub infrastructure since trac
broke and I changed the emails to point to GitHub instead. I also often do
code reviews with other devs on a personal GHC fork on github before
merging in.

I believe it would also help encourage more contributors (especially for
libraries) but others have expressed disagreement with this point of view
in the past and I'm not in hold of data.

Either way, I'm glad git bisect may soon work. We'll finally be able to use
the whole feature set of a version control tool :)  (other piece was the
move from darcs -> git which gave us a working annotate).

> Simon Peyton-Jones <simonpj at microsoft.com>:
> > For the avoidance of doubt, I totally support what Austin and Johan are
> saying:
> >
> > I find the current setup confusing too.
> >
> > I'm totally persuaded of the merits of git bisect etc.
> >
> > I am the opposite of a git power-user (a git weedy-user?).  I will be
> content to do whatever I'm told workflow-wise, provided I am told clearly
> in words of one syllable.
> >
> > I *very strongly* want to reduce barriers to entry for would-be
> contributors, and this is clearly a barrier we could lower.  Making Kazu,
> Austin, Johan, etc more productive is massively valuable.
> >
> > There may be some history to how we arrived at this point, but that
> should not constrain for the future.  We can change our workflow.   I would
> want Ian and Simon to be thoroughly on board, but I regard the current
> setup as totally open to improvement.  Please!
> >
> > BTW, Ian has written it up quite carefully here:
> http://hackage.haskell.org/trac/ghc/wiki/Repositories, and the linked
> page http://hackage.haskell.org/trac/ghc/wiki/Repositories/Upstream.
> >
> > Simon
> >
> >
> >
> > | -----Original Message-----
> > | From: ghc-devs-bounces at haskell.org [mailto:
> ghc-devs-bounces at haskell.org]
> > | On Behalf Of Austin Seipp
> > | Sent: 05 June 2013 07:35
> > | To: Johan Tibell
> > | Cc: ghc-devs at haskell.org
> > | Subject: Re: how to checkout proper submodules
> > |
> > | I absolutely agree here, FWIW. We should only do this if there is a
> > | clear consensus on doing so and everyone doing active development is
> > | comfortable with it. And it's entirely possible submodules are
> > | inadequate for some reason that I'm not aware of which is a
> > | show-stopper.
> > |
> > | However, the notion of impact-on-contributors cuts both ways. GHC has
> > | an extremely small team of hackers as it stands, and we are lucky to
> > | have *amazing* contributors like Kazu, Andreas, yourself, Simon &
> > | Simon, and numerous others help make GHC what it is. Much of this is
> > | volunteer work. But as the Haskell community grows, and we are at a
> > | loss of other full-time contributors like Simon Marlow, I think we are
> > | beginning to see the strain on GHC and its current contributors. So,
> > | it's important to evaluate what we're doing right and wrong. This
> > | feedback loop is always present even if seasoned contributors can live
> > | with it - but new contributors will definitely be impacted.
> > |
> > | In this instance, I honestly find it disheartening that the answer to
> > | things like "getting older revisions of the source code in HEAD," or
> > | techniques like bisection is basically "that doesn't work." The second
> > | is unfortunate, but the latter is pretty legitimately worrying. It
> > | would be one thing if this was a one-off occurrence of some odd
> > | developer-workflow. But I have answered the fundamental question here
> > | (submodules vs free-floating clones) a handful of times myself at
> > | least, experienced the pain of the decision myself when doing
> > | rollbacks, and I'm sure other contributors can say the same.
> > |
> > | GHC is already a large, industry-strength software project with years
> > | of work put behind it. The barrier to entry and contribution is not
> > | exactly small, but I think we've all done a good job. I'd love to see
> > | more people contributing. But I cannot help but find these discussions
> > | a bit sad, where contributors are impaired due to regular/traditional
> > | development workflows like rollbacks are rendered useless - due to
> > | some odd source control discrepancy that nobody else on the planet
> > | seems to suffer from.
> > |
> > | I guess the short version is basically that that you're absolutely
> > | right: the time of Simon, Ian, and other high-profile contributors is
> > | *extremely* important. But I'd also rather not have people like Kazu
> > | potentially spend hours or even days doing what simple automation can
> > | achieve in what is literally a few keystrokes, and not only that - par
> > | for the course for other projects. This ultimately impacts the
> > | development cycles of *everybody*. And even if Kazu deals with it -
> > | what about the next person?
> > |
> > | On Wed, Jun 5, 2013 at 12:12 AM, Johan Tibell <johan.tibell at gmail.com>
> > | wrote:
> > | > The latest git release has improved submodules support some so if we
> now
> > | > thing the benefits of submodules outweigh the costs we can discuss
> if we
> > | > want to change to policy. I don't want to make that decision for
> other GHC
> > | > developers that spend much more time on GHC than I (e.g. SPJ). Their
> > | > productivity is more important than any inconveniences the lack of
> > | > consistent use of submodules might cause me.
> > |
> > |
> > | --
> > | Regards,
> > | Austin - PGP: 4096R/0x91384671
> > |
> > | _______________________________________________
> > | ghc-devs mailing list
> > | ghc-devs at haskell.org
> > | http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130605/fa13c02d/attachment-0001.htm>