[GHC] #16200: Mechanical checking of submodule versions for releases

[GHC]

#16200: Mechanical checking of submodule versions for releases
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Continuous        |              Version:  8.6.3
  Integration                        |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by bgamari:

Old description:

> In the past there have been a few cases where we have put out GHC
> releases which have shipped with submodule versions which do not
> correspond with a released package version (e.g. #16199).
>
> This should never happen. In principle the output of `git submodule`
> should be checked before a release is cut to ensure that all submodules
> point to tags. However, in practice this has proved to be insufficient
> due to two sources of false-positives:
>
>  1. our old mirroring infrastructure often failed to pick up tags
>  2. often we get away with a mere Hackage revision, which typically
> aren't tagged
>
> Thankfully (1) should no longer be a problem with the move to GitLab.
> Moreover, now since we finally have reliable CI we can automate release
> creation. However, it's not entirely clear how to reliably verify the
> consistency of submodules in light of problem (2).
>
> Unfortunately, it's quite tricky to avoid due to the existence of

New description:

 In the past there have been a few cases where we have put out GHC releases
 which have shipped with submodule versions which do not correspond with a
 released package version (e.g. #16199).

 This should never happen. In principle the output of `git submodule`
 should be checked before a release is cut to ensure that all submodules
 point to tags. However, in practice this has proved to be insufficient due
 to two sources of false-positives:

  1. our old mirroring infrastructure often failed to pick up tags
  2. often we get away with a mere Hackage revision, which typically aren't
 tagged

 Thankfully (1) should no longer be a problem with the move to GitLab.
 Moreover, now since we finally have reliable CI we can automate release
 creation. However, it's not entirely clear how to reliably verify the
 consistency of submodules in light of problem (2).

--

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16200#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler