Hadrian

[Herbert Valerio Riedel]

Hi Moritz (et al.),

On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:

> a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for 
>    all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand
>    a subtree, it's essentially integrating everything into the main tree.  So this looks more like the submodule to subtree
>    conversion, when hadrian development is switched over to phabricator?

Fwiw, using a submodule makes sense imho if hadrian is supposed to
remain a submodule on the long-term; as transitioning from submodule <->
non-submodule is something Git doesn't handle to well automatically
(we've had fun with that when we restructured ghc.git into the current
structure...)

Also, a submodule has the benefit of ticket references clearly referring
to a different numbering namespace w/o having to rewrite all ticket &
commit-hash references (which is often overlooked; I for one tend to
refer quite often to other commit shas in my commits, and they also
result when you 'git cherry-pick -x')

So, what's the long-term plan for Hadrian repo-wise? Is it going to
remain externally maintained on GitHub, or will it be integrated into
GHC HQ's infrastucture which means using Phabricator (which may pose its
own challenge, as Phabricator, like Trac, uses globally unique ticket
numbers, rather than per-project numbering)?

If it is to be a submodule, we (and by that I mean myself; it doesn't
take long) also need to setup mirroring from snowleopard/hardian to
git://git.haskell.org, and from there to to github.com/ghc/hadrian for
technical reasons.

> b) should we really hardcode the full url to hadrian tickets? wouldn't hadrian/#xxx suffice? Assuming for a moment hadrian
>    would move into the github.com/haskell org or something, while the linkes would likely (due to githubs url redirection)
>    keep on working, until someone recreates a snowleopard/hardian
>    repo, but not necessarily correct anymore.

Note that GitHub doesn't support the abbreviated hadrian#xxx syntax; you
*have* to prefix it by the organization/user, in order for GitHub to
recognize a ticket reference; i.e. you *have* to use one of


- https://github.com/snowleopard/hadrian/issues/123  (or possibly .../pull/123)

- snowleopard/hadrian#123

- #123

- GH-123

for GitHub to recognize the issue reference.

anything else won't be recognized.

Moreover, github.com/haskell/ is not a good place for Hadrian since it's
a too GHC-specific tooling; if anywhere, it would rather end up together
with the other GHC repos in the /ghc/ org at
https://github.com/ghc/hadrian (or something slightly different; we need
reconcile this with our GHC mirroring scheme; that's may be a bit
tricky).

-- hvr