<div dir="ltr">This all sounds to me like we are trying to fix PVP by adding errors. I'm ok to declare<div>PVP bankruptcy. If it's too hard to be practically used, we need to find a different solution.</div><div><br></div><div>But this problem to me sounds more like we rather need some automation? What we</div><div>seem to essentially want to achieve is guarantee that component integration is not</div><div>faulty? It all sounds to me like what we really want is an automated solution that flags</div><div>packages that were broken by changes in their dependencies. And then be trivially able</div><div>to address those (and open PRs). Though I guess you'd also need to deal with</div><div>version bounds, the inverse of missing-fields would be overspecified fields, and thus</div><div>the library that depends on something that added more fields, now needs a hard lower</div><div>bound after adding the fields?</div><div><br></div><div><a href="https://github.com/ghc-proposals/ghc-proposals/pull/617">https://github.com/ghc-proposals/ghc-proposals/pull/617</a> likely also would benefit from<br></div><div>automation. Maybe reboot hackage matrix in some form? Can someone point me in</div><div>the right direction?</div><div><br></div><div>Best,</div><div> Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Oct 2023 at 23:57, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Montag, dem 09.10.2023 um 16:53 +0100 schrieb Simon Marlow:<br>
> On Mon, 9 Oct 2023 at 15:22, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> > <br>
> > That is my understanding, yes.  Oleg, who suggested this originally (I<br>
> > just wrote it up) says (see motivation section of the proposal)<br>
> > <br>
> > > not having -Wsevere=missing-methods by default essentially prevents <br>
> > > any (true) breakage assessment of adding new, non-defaulted members<br>
> > > to existing type-classes.<br>
> <br>
> <br>
> If the goal is to do a breakage assessment, couldn't you make the<br>
> change to your library and then build all of Hackage with `--ghc-<br>
> option=-Werror=severe`?<br>
<br>
Not if Hackage already fails with -Werror=severe even without the<br>
change under assessment. But we should ask Oleg on Github, I am just<br>
relaying what I thought his motivation was.<br>
<br>
Should we send this back for revision? It seems there is plenty of<br>
discussion going on here and on github. (Is there an equivalent of<br>
Wadler’s law about “compiler flags” instead of “whitespace”?)<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>