- ghc-devs - Haskell.org

答复: ghc-devs Digest, Vol 172, Issue 40
by BalterNotz 27 Dec '17

27 Dec '17

发送自 Windows 10 版邮件应用发件人: ghc-devs-request(a)haskell.org 发送时间: 2017年12月27日 20:32 主题: ghc-devs Digest, Vol 172, Issue 40

1 0

CircleCI failed for me
by Richard Eisenberg 26 Dec '17

26 Dec '17

Hi devs, I've enabled CircleCI on my GitHub fork of GHC in order to get good validation results. This worked several months ago. But now, I see failures around performance tests: https://circleci.com/gh/goldfirere/ghc/12 <https://circleci.com/gh/goldfirere/ghc/12> This is a tiny patch on top of HEAD; I can't imagine my patch is at fault here. Does anyone know what settings I should look into to fix this? Thanks! Richard

1 0

RE: Can't push to haddock
by Simon Peyton Jones 20 Dec '17

20 Dec '17

| It's for technical reasons, and the strongest one being: GitHub doesn't | allow us to establish strong invariants regarding submodule gitlink | referential integrity for submodules (which I implemented a couple years ago | for git.haskell.org) Interesting. It'd be good to document what the technical reasons are. For example I don’t know what the strong invariants are. A good place to describe them might be the Repositories pages https://ghc.haskell.org/trac/ghc/wiki/Repositories Many thanks Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 18 December 2017 11:13 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Can't push to haddock | | On Mon, Dec 18, 2017 at 10:01 AM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > But why don’t we just pull from github rather than mirroring on | > git.haskell.org? | | It's for technical reasons, and the strongest one being: GitHub doesn't | allow us to establish strong invariants regarding submodule gitlink | referential integrity for submodules (which I implemented a couple years ago | for git.haskell.org)

7 13

ghc-prim 0.5.1.1 not on Hackage
by Michael Snoyman 20 Dec '17

20 Dec '17

The Stackage issue tracker just received an issue about ghc-prim 0.5.1.1. https://github.com/fpco/stackage/issues/3115 This version of the package has not been uploaded to Hackage, so: * The Stackage snapshots refer to 0.5.1.1 * The stackage.org documentation shows version 0.5.1.1 * `stack unpack` and `cabal unpack` both fail on ghc-prim-0.5.1.1 Also, it appears that the GHC 8.2.2 release notes still refer to ghc-prim 0.5.1.0. I'm happy to file an issue for this, but last time this popped up it was unclear if the issue should be filed on GHC Trac or the Hackage Trustees issue tracker. Michael

3 2

Re: Can't push to haddock
by Gershom B 20 Dec '17

20 Dec '17

> You're also assuming github doesn't suddenly pull a SourceForge (or a > Gitorious for that matter). Business cares not what it steamrolls in the > name of profit. > > I fail to understand why, with multiple examples of the folly of this > belief out there, people are still willing to bet on *this* company being > *different* from all others and absolutely safe to trust. What the heck is everyone arguing over? The initial statement was that even if we moved everything to github "We'd need mirroring anyway". That's it! There's no either/or involved. Just a statement that when you have data in one location, no matter how trustworthy, you want a backup as well. And ideally you want the backup under your control. We can debate moving anything anywhere all we want, but the idea that stuff should also be backed up, regardless, in a source not under third-party control, seems inoffensive and besides the point. --Gershom

2 1

Re: [GHC DevOps Group] Release policies
by Boespflug, Mathieu 18 Dec '17

18 Dec '17

I think Mikhail's point is that if a package says build-type: Simple, then we know exactly what its Setup.hs says, and therefore also which part of the Cabal API it's using. Easy enough to keep that part stable even if others change. Case in point: Cabal-2.0 brought a number of changes to the overall API, but nothing that broke calling defaultMain from Distribution.Simple (which is what a build-type: Simple script does). At the end of the day the consumers of the wider Cabal API are pretty small. A substantial number of misc packages on Hackage do it but rarely heavily. Other than that it essentially comes down to Stack, cabal-install, Haskell For Mac and... any others? My takeaway from the discussion so far is that the number of heavy consumers looks small enough that a draconian BC policy for Cabal-the-library sounds overkill, provided, crucially, that everything is in place, by GHC feature freeze at the very latest, to allow a smooth migration. A "smooth transition" means having a migration guide available before start of feature freeze etc, but to Ben's concern stated earlier in this thread (about GHC/upstream coupling), ideally also a release. I should note that to the extent that GHC tracks upstream releases only (not git commits in unknown state), GHC can be released on a timely schedule without needing any coordination from upstream maintainers to await new releases on their part. So quite apart from the Cabal thing specifically, it's worth thinking about asking that the versions of all upstream packages only make it into GHC, at the behest of their respective maintainers, after a new release of upstream is made. This was already proposed earlier in the thread: > * [Proposal:] GHC does not track git commits of upstream dependencies > in an unknown state of quality, but tracks vetted and tested releases > instead. Potentially, this could even mean drastically cutting down on the number of git submodules carried in the GHC repo. Since these packages could as well be downloaded from Hackage. On 18 December 2017 at 05:04, Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io> wrote: > Yes, you are right Haskell for Mac also links against Cabal-the-library and API changes have regularly required me to fix my code. I guess, I have never been particularly stressed about it, because I also link against GHC API and that doesn’t even know how to spell API stability — i.e., changes required by Cabal are usually drowned out by the chaos inflicted by GHC. > > In any case, you are making a good point. > > Mikhail, I don’t understand your response to Mathieu at all. What does the build-type have to do with this? > > Cheers, > Manuel > >> 15.12.2017, 19:41 Boespflug, Mathieu <m(a)tweag.io>: >> >> Thanks for the feedback, Michael. >> >> Manuel, I believe you are also a Cabal-the-library consumer in Haskell For Mac? >> >> Michael, you brought up another problem tangentially related to the >> original integer-gmp issue but that was not in my original list >> earlier in this thread: >> >> * Cabal-2.0.0 had breaking changes in the API. >> >> This means that by association GHC itself broke BC, because it shipped >> with Cabal-2.0, without the usual grace period. >> >> Now, there are far fewer users of Cabal than of base. All, Michael in >> his previous email seems to be okay with breaking changes in Cabal >> given the conditions he stated (2 months grace period, advance notice >> of when the 2 months start). And perhaps this points to the lack of a >> need for the regular grace period applying to Cabal. How many other >> users of Cabal-the-library are there? In principle, every single >> Hackage package out there, which all have a Setup.hs script. Most of >> them are trivial, but how many did break because of these API changes? >> I for one am pretty happy for Cabal to move fast, but I'm concerned >> that these breaking changes happened without any kind of advance >> notice. To Simon's original point - there does not to be a clear >> policy and a good process surrounding Cabal itself and other GHC >> dependencies. So far we discussed mostly metadata changes, not API >> changes. >> >> And to be clear, folks did get some (post facto) notice in September: >> http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html. That's helpful, but >> I submit that in the future this really should be part of the GHC >> release announcement (which happened over a month before that), and in >> fact a migration guide circulated before the feature freeze, so >> downstream tooling authors can adapt. If this is not possible, then >> perhaps it's premature for GHC to include that given Cabal release. >> Again, GHC should always have the option to stick to the old Cabal >> version until things get ironed out. >> >> >> On 15 December 2017 at 08:42, Michael Snoyman <michael(a)snoyman.com> wrote: >>> >>> >>> On Thu, Dec 14, 2017 at 12:27 PM, Boespflug, Mathieu <m(a)tweag.io> wrote: >>> >>> [snip] >>> >>>> * Or a middle ground: make feature freeze a thing. Meaning that for a >>>> couple of months before a major GHC release, the major new Cabal isn't >>>> technically released yet, but like GHC itself within this period, it's >>>> pretty staid, so not so much a moving target, and something downstream >>>> tooling authors can possibly adapt to even without any grace period on >>>> new metadata features. This assumes that the 2 months of feature >>>> freeze are enough time for downstream tooling. Thoughts from any of >>>> those maintainers? >>>> >>> >>> Short answer: if there's a clear idea in advance of when this feature freeze >>> is going to happen, I think we can coordinate releases of downstream tooling >>> (Stack being the most important, but stackage-curator playing in as well) so >>> that 2 months is sufficient. I'll talk with the rest of the Stack team to >>> see if there are any concerns. >>> >>> Longer answer: Stack intentionally avoids depending on the internals of >>> Cabal wherever possible. Instead of calling library functions directly from >>> within Haskell code to perform builds, for example, it interacts with the >>> Setup.hs files over their command line interface.[1] This has two results: >>> >>> * Stack can usually start using new GHC/Cabal versions without a new Stack >>> release, since it's just shelling out for the actual build >>> * There's not usually very much code churn needed in Stack to upgrade to a >>> newer Cabal release >>> >>> This past release was an exception because of all of the changes that >>> landed, both the new cabal grammar to support the ^>= operator (making the >>> old parser incapable of lossily parsing new files) and API changes (I think >>> mostly around Backpack, though there was some code cleanup as well). In >>> particular, the main interface we need from Cabal—the package description >>> data types and parser—changed significantly enough that it took significant >>> effort to upgrade. There were also new features added (like sub libraries >>> and foreign libraries) that weren't immediately supported by the old Stack >>> version, and had to be manually added in. >>> >>> Tying this up: generally upgrading to a new Cabal release should be fine, >>> and the only concern I'd have is fitting it into a release schedule with >>> Stack. The complications that could slow that down are: >>> >>> * Changes to the command line interface that Stack uses (hopefully those are >>> exceedingly rare) >>> * Major overhauls to the Stack-facing API >>> >>> Michael >>> >>> [1] This allows for more reproducible builds of older snapshots, insuring >>> that the exact same Cabal library is performing the builds >> _______________________________________________ >> Ghc-devops-group mailing list >> Ghc-devops-group(a)haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group >

3 2

RE: Can't push to haddock
by Simon Peyton Jones 18 Dec '17

18 Dec '17

| Yes, the mirroring has a little bit of latency (assuming the mirroring | trigger event notification from github to git.haskell.org didn't get | lost). How much time did you wait between pushing to github and | ghc.git? I didn't allow any time -- I didn't know that time was needed. Perhaps we should add a note to https://ghc.haskell.org/trac/ghc/wiki/Repositories to explain? Under "Updating sub-repos" perhaps. I wonder if it'd be worth us articulating the reason why some submodules live in github, but some live in git.haskell.org -- with only mirroring github. I'm sure there's a rationale but I don't get it yet. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 07 December 2017 17:57 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Can't push to haddock | | Hi Simon, | | Yes, the mirroring has a little bit of latency (assuming the mirroring | trigger event notification from github to git.haskell.org didn't get | lost). How much time did you wait between pushing to github and | ghc.git? | | On Thu, Dec 7, 2017 at 6:53 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > But when I try to push the GHC patch, I get this message | > | > Ah… it worked after a while. Maybe a mirroring thing? | > | > But in pushing to GHC I saw: | > | > git push | > | > Counting objects: 45, done. | > | > Delta compression using up to 32 threads. | > | > Compressing objects: 100% (45/45), done. | > | > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done. | > | > Total 45 (delta 43), reused 0 (delta 0) | > | > remote: performing commit message validations... | > | > remote: Commit message validation passed! | > | > remote: performing submodule-ref update validations... | > | > remote: Submodule update(s) detected in | > fa29df02a1b0b926afb2525a258172dcbf0ea460: | > | > remote: utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65 | > | > remote: utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959 | > | > remote: OK | > | > remote: performing whitespace validations... | > | > remote: whitespace validation passed! | > | > remote: mirroring ssh://git@git.haskell.org/ghc to | > ssh://git@github.com/ghc/ghc ... | > | > remote: To ssh://git@github.com/ghc/ghc | > | > remote: 5f332e1..fa29df0 master -> master | > | > remote: running notifier | > | > To ssh://git@git.haskell.org/ghc.git | > | > 5f332e1..fa29df0 HEAD -> master | > | > simonpj@cam-05-unx:~/code/HEAD$ | > | > I did not intend to monkey around with hsc2hs. I can’t think how | that | > happened, or whether it matter. | > | > With many apologies, would a wiser person that me like to see if | I’ve | > accidentally messed up hsc2hs. | > | > Thanks | > | > Simon | > | > | > | > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > Simon Peyton Jones via ghc-devs | > Sent: 07 December 2017 17:32 | > To: ghc-devs(a)haskell.org | > Subject: Can't push to haddock | > | > | > | > I’m trying to push a patch that needs a supporting change to | haddock. | > | > I’ve pushed the haddock change to the ghc-head branch of | > ssh://git@github.com/haskell/haddock.git, which is (according to | > ‘packages’) the relevant haddock upstream repo. | > | > But when I try to push the GHC patch, I get this message | > | > bash$ git push | > | > Counting objects: 45, done. | > | > Delta compression using up to 32 threads. | > | > Compressing objects: 100% (45/45), done. | > | > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done. | > | > Total 45 (delta 43), reused 0 (delta 0) | > | > remote: performing commit message validations... | > | > remote: Commit message validation passed! | > | > remote: performing submodule-ref update validations... | > | > remote: Submodule update(s) detected in | > fa29df02a1b0b926afb2525a258172dcbf0ea460: | > | > remote: utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65 | > | > remote: *FAIL* commit not found in submodule repo ('../haddock.git') | > | > remote: or not reachable from persistent branches | > | > remote: hooklet hooks/update.secondary.d/check-submodule-refs failed | > | > remote: hooks/update.secondary died | > | > remote: error: hook declined to update refs/heads/master | > | > To ssh://git@git.haskell.org/ghc.git | > | > ! [remote rejected] HEAD -> master (hook declined) | > | > error: failed to push some refs to | 'ssh://git@git.haskell.org/ghc.git' | > | > simonpj@cam-05-unx:~/code/HEAD$ | > | > | > | > What’s up? I have pushed the haddock commit! | > | > THanks | > | > Simon | > | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C684b5c6cdac34213317708d5 | 3d9be387%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364826622509770 | 90&sdata=kMhG2iTALLRxhwyDw%2BzTN8VvMMn%2FqfvnSn9cPm0AK4Q%3D&reserved=0 | >

2 2

Release policies
by Simon Peyton Jones 16 Dec '17

16 Dec '17

Dear GHC devops group The conversation on Trac #14558<https://ghc.haskell.org/trac/ghc/ticket/14558> suggests that we might want to consider reviewing GHC's release policies<https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases>. This email is to invite your input. The broad questions is this. We want GHC to serve the needs of all its users, including downstream tooling that uses GHC. What release policies will best support that goal? For example, we already ensure that GHC 8.4 can be compiled with 8.2 and 8.0. This imposes a slight tax on GHC development, but it means that users don't need to upgrade quite as often. (If the tempo of releases increases, we might want to increase the window.) Trac #14558 suggests that we might want to ensure the metadata on GHC's built-in libraries is parsable with older Cabals. One possibility would be this: * Ensure that the Cabal metadata of non-reinstallable packages (e.g. integer-gmp) shipped with GHC be parsable by the Cabal versions shipped with the last two major GHC releases [i.e. have a sufficiently old cabal-version field]. That is, in general a new Cabal specification will need to be shipped with two GHC releases before GHC will use start using its features in non-reinstallable packages. * Upholding this policy won't always be possible. There may be cases (as is the case Hadrian for GHC 8.4) where the benefit of quickly introducing incompatible syntax outweighs the need for compatibility. In this (hopefully rare) case we would explicitly advertise the incompatibility in the release documentation, and give as much notice as possible to users to allow downstream tools to adapt. * For reinstallable packages, of which GHC is simply a client (like text or bytestring), we can't reasonably enforce such a policy, because GHC devs have no control over what the maintainers of external core libraries put in their Cabal files. This is just a proposal. The narrow questions are these: * Would this be sufficient to deal with the concerns raised in #14558? * Is it necessary, ow would anything simpler be sufficient? * What costs would the policy impose on GHC development? * There may be matters of detail: e.g. is two releases the right grace period. Would one do? Both the broad question and the narrow ones are appropriate for the Devops group. Thanks! Simon

4 8

GHC-API unloading from external interpreter
by Németh Boldizsár 16 Dec '17

16 Dec '17

Dear GHC Developers, I'm using the GHC API to load Haskell modules and extract their syntax tree. I need to generate code where TH is used (by default I do in-memory linking). I've run into some trouble with external interpreter. When -fexternal-interpreter is NOT set, I use Linker.unload to remove bytecode from the global linker before reloading modules. However it is not applicable when external interpreter is used and I could not find corresponding functionality in the GHCi module (where communication with external interpreter is implemented). I've recently created 2 tickets related to this question: https://ghc.haskell.org/trac/ghc/ticket/14576, https://ghc.haskell.org/trac/ghc/ticket/14577 Can someone help me with this problem? Best Regards, Boldizsár Németh

2 2

Re: Fwd: Release policies
by Gershom B 15 Dec '17

15 Dec '17

Mathieu: I think the points about better tooling for documenting the correct claims in the release process are well taken. Updating the release notes manually leaves way too much room for error. However, I think you are incorrect that GHC 8.2.1 and 8.2.2 did not have cabal-install 1.24 support. They did. it works with them. I used it! The fact that the cabal files for builtin libraries use Cabal-2 syntax does not cause a problem. I think elsewhere Mikhail has corrected your timeline a bit. The general point is that Cabal-the-library and ghc releases do tend to be in tandem. But it is also the case that this happens because they are often developed in a coupled fashion. This in not really different than other builtin libs to GHC. They are necessarily coupled to changes in the compiler, and so end up being released together. Our process for making sure they are actually uploaded is absolutely error-prone as is the process for documenting what occurs in release notes. But I don't think we can simply by fiat decouple this stuff -- rather, this needs to occur on a technical level first, before other policies can really even be considered. Onto the concrete ideas: > * GHC should never under any circumstance ship with an unreleased version > of any independently maintained dependency. Cabal is one such dependency. > This should hold true for anything else. We could just add that policy to > the Release Policy. Yes, this is a good policy. Sometimes in the drive for a release, GHC will run ahead of a dependencies' upload by a bit. (Iirc this happened at one point in the past for bytestring, but this was some years ago). It is always better to hold things by a few days to get the dependency released first. > * Stronger still, GHC should not switch to a new major release of a > dependency at any time during feature freeze ahead of a release. E.g. if > Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair > game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet. I don't think this works, in terms of coupled dependencies. If/when Cabal-3 is developed it will almost certainly be in tandem with GHC support. > * GHC does have control over reinstallable packages (like text and > bytestring): GHC need not ship with the latest versions of these, if indeed > they introduce breaking changes that would contravene the 3-release policy. Right, but this won't occur, because those libs are already under the control of the libraries committee and abide by the policy. > * Because there are far fewer consumers of metadata than consumers of say > base, I think shorter lead time is reasonable. At the other extreme, it > could even be just the few months during feature freeze. Right. There's not a sufficient quantity of metadata-consuming downstream tooling to motivate a long lead. And furthermore, the examples I can think of -- tracking dependencies for notifications or graphs -- have no need of pulling this data out of ghc-builtin libraries anyway, as they're for exploring the _userland_ portion of the package world regardless. (The other key example -- stack -- can also choose to ignore the metadata of builtin libs without harm). The general motivation of making a "feature freeze" more of a "freeze all the moving parts, really" I do agree with. Having a real freeze is part of a better release process, and it should allow all the downstream consumers of everything more time to really catch up. This is just one instance of that need. > Finally, a question for discussion: > > * Hackage allows revising the metadata of an uploaded package even without > changing the version number. This happens routinely on Hackage today by the > Hackage trustees. Should this be permitted for packages whose release is > completely tied to that of GHC itself (like integer-gmp)? It is rare that this is needed, but the ability just served us well -- editing integer-gmp to remove the new syntax was very useful, as it let us fix up old stack nightlies. Like all revisions, these should be made with some care and thought, but since we've just seen why it was helpful, I'd hate to now say we can't do it again if some other unforseen circumstance crops up. Regards, Gershom > Hi Simon, > > feedback from downstream consumers of Cabal metadata (e.g. build tool > authors) will be particularly useful for the discussion here. Here are my > thoughts as a bystander. > > It's worth trying to identify what problems came up during the integer-gmp > incident in Trac #14558: > > * GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said > otherwise. > * GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the > release notes that cabal-install-1.24 (and by implication any other build > tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only > works with cabal-install version 1.24 or later. Please upgrade if you have > an older version of cabal-install." > * GHC 8.2.2 also claimed Cabal-1.24 support. > * GHC 8.2.1 was released in July 2017 with Cabal-2.0.0.2, a brand new major > release with breaking changes to the metadata format, without much lead > time for downstream tooling authors (like Stack) to adapt. > * But actually if we look at their respective release notes, GHC 8.2.1 was > relased in July 2017, even though the Cabal website claims that > Cabal-2.0.0.2 was released in August 2017 (see > https://www.haskell.org/cabal/download.html) So it looks like GHC didn't > just not give enough lead time about an upstream dependency it shipped > with, it shipped with an unreleased version of Cabal! > * Libraries that ship with GHC are usually also uploaded to Hackage, to > make the documentation easily accessible, but integer-gmp-1.0.1.0 was not > uploaded to Hackage until 4 months after the release. > * The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage differed from > the metadata that was actually in the source tarball of GHC-8.2.1 and > GHC-8.2.2. > * The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage included > Cabal-2.0 specific syntactic sugar, making the metadata unreadable using > any tooling that did not link against the Cabal-2.0.0.2 library (or any > later version). > * It so happened that one particular version of one particular downstream > build tool, Stack, had a bug, compounding the bad effects of the previous > point. But a new release has now been made, and in any case that's not a > problem for GHC to solve. So let's keep that out of the discussion here. > > So I suggest we discuss ways to eliminate or reduce the likelihood of any > of the above problems from occurring again. Here are some ideas: > > * GHC should never under any circumstance ship with an unreleased version > of any independently maintained dependency. Cabal is one such dependency. > This should hold true for anything else. We could just add that policy to > the Release Policy. > * Stronger still, GHC should not switch to a new major release of a > dependency at any time during feature freeze ahead of a release. E.g. if > Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair > game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet. > * The 3-release backwards compat rule should apply in all circumstances. > That means major version bumps of any library GHC ships with, including > base, should not imply any breaking change in the API's of any such library. > * GHC does have control over reinstallable packages (like text and > bytestring): GHC need not ship with the latest versions of these, if indeed > they introduce breaking changes that would contravene the 3-release policy. > * Note: today, users are effectively tied to whatever version of the > packages ships with GHC (i.e. the "reinstallable" bit is problematic today > for various technical reasons). That's why a breaking change in bytestring > is technically a breaking change in GHC. > * The current release policy covers API stability, but what about metadata? > In the extreme, we could say a 3-release policy applies to metadata too. > Meaning, all metadata shipping with GHC now and in the next 2 releases > should be parseable by today's version of Cabal and downstream tooling. Is > such a long lead time necessary? That's for build tool authors to say, and > a point to negotiate with GHC devs. > * Because there are far fewer consumers of metadata than consumers of say > base, I think shorter lead time is reasonable. At the other extreme, it > could even be just the few months during feature freeze. > * The release notes bugs mentioned above and the lack of consistent upload > to Hackage are a symptom of lack of release automation, I suspect. That's > how to fix it, but we could also spell out in the Release Policy that GHC > libraries should all be on Hackage from the day of release. > > Finally, a question for discussion: > > * Hackage allows revising the metadata of an uploaded package even without > changing the version number. This happens routinely on Hackage today by the > Hackage trustees. Should this be permitted for packages whose release is > completely tied to that of GHC itself (like integer-gmp)? > > Best, > > Mathieu > > > On 13 December 2017 at 17:43, Simon Peyton Jones via ghc-devs < > ghc-devs(a)haskell.org> wrote: > >> Dear GHC devops group >> >> The conversation on Trac #14558 >> <https://ghc.haskell.org/trac/ghc/ticket/14558> suggests that we might >> want to consider reviewing GHC’s release policies >> <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases>. >> This email is to invite your input. >> >> The broad questions is this. We want GHC to serve the needs of all its >> users, including downstream tooling that uses GHC. What release policies >> will best support that goal? For example, we already ensure that GHC 8.4 >> can be compiled with 8.2 and 8.0. This imposes a slight tax on GHC >> development, but it means that users don't need to upgrade quite as often. >> (If the tempo of releases increases, we might want to increase the window.) >> >> Trac #14558 suggests that we might want to ensure the metadata on GHC’s >> built-in libraries is parsable with older Cabals. One possibility would be >> this: >> >> - Ensure that the Cabal metadata of non-reinstallable packages (e.g. >> integer-gmp) shipped with GHC be parsable by the Cabal versions shipped >> with the last two major GHC releases [i.e. have a sufficiently old >> cabal-version field]. That is, in general a new Cabal specification will >> need to be shipped with two GHC releases before GHC will use start using >> its features in non-reinstallable packages. >> - Upholding this policy won't always be possible. There may be cases >> (as is the case Hadrian for GHC 8.4) where the benefit of quickly >> introducing incompatible syntax outweighs the need for compatibility. In >> this (hopefully rare) case we would explicitly advertise the >> incompatibility in the release documentation, and give as much notice as >> possible to users to allow downstream tools to adapt. >> - For reinstallable packages, of which GHC is simply a client (like >> text or bytestring), we can’t reasonably enforce such a policy, because GHC >> devs have no control over what the maintainers of external core libraries >> put in their Cabal files. >> >> This is just a proposal. The narrow questions are these: >> >> - Would this be sufficient to deal with the concerns raised in #14558? >> - Is it necessary, ow would anything simpler be sufficient? >> - What costs would the policy impose on GHC development? >> - There may be matters of detail: e.g. is two releases the right grace >> period. Would one do? >> >> Both the broad question and the narrow ones are appropriate for the Devops >> group. >> >> Thanks! >> >> Simon >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >

5 14