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@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