Hadrian

[Moritz Angermann]

> On Oct 20, 2017, at 6:24 PM, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> 
> 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.

I would assume that hadrian will be developed on github for a while, to not
disturb the current workflow. But I'm happy to be corrected, when wrong here. 
After reading up on git-subtree[1][2], which sounds to me like subsuming one
repo in another one and requiring a set of different commands to handle it.
Maybe I'm just too used to git submodules. But as all the other externals in
the ghc tree are submodules, I'd prefer the consistency.  Knowing myself, I'd
probably screw up pushing changes back upstream into hadrian if its workflow
is different from e.g. the libraries, ... libffi-tarballs with the orphan
branches is already something that needs to be taken special care of...

>> 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).

I didn't specifically care about github auto-linking features here. Primarily
about giving tickets a prefix. And not necessarily hardcoding some github url
into ticket numbers.

Cheers,
 Moritz

--
[1]: https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree
[2]: http://alistra.ghost.io/2014/11/30/git-subtree-a-better-alternative-to-git-submodule/