<div dir="ltr">Hi there!<br><div><br></div><div>So a few more discussions have come up. And they have mainly centered</div><div>around the question of quality assurance. Cutting GHC releases is time</div><div>consuming and not trivial. And those people would need to take ownership</div><div>of those releases and stand by them. How do we ensure that backports do</div><div>not inadvertently break working compiler? I'm completely against preventing</div><div>new contributors to help with making releases on the ground that things can</div><div>go wrong. This would inevitably just end up preventing people form even</div><div>trying, and how do you get good at something if you can't even try to get good</div><div>at it?</div><div><br></div><div>So the question then is: what can we do to improve/ensure quality of releases?</div><div>We certainly have the test-suite, but that might have holes, and backporting the</div><div>test-suite will only work so far. Language features that change stdout/stderr</div><div>will inevitably be fixed in newer test-suites to accomodate newer compilers, but</div><div>will not work with older compilers.</div><div><br></div><div>However, we have a large body of public libraries on hackage. And a curated</div><div>set of packages per compiler in the form Stackage LTS sets. We have something</div><div>slightly similar for HEAD with the hackage head overlay. For older compilers</div><div>we can rely on something more mature!</div><div><br></div><div>Thus, if we can build some automation to test a compiler against an existing set</div><div>of packages, and run their test-suites. There will inevitably be failures, but we'd</div><div>be interested in looking at the drivitive only anyway. If the same set of tests fail</div><div>that previous compilers failed at, I don't think that should be much of concern. If</div><div>fewer tests fail, it would indicate something might have been fixed, or the test</div><div>now surfaces some new behaviour that we might want to look at. Worst case</div><div>would be new test that fail, but didn't before. This should raise red flags and</div><div>either have a *very* good argument for why the backport is still the right thing to</div><div>do and the test-failures are actually faulty tests, or the backport should just not</div><div>be performed.</div><div><br></div><div>In the end it will be about striking a balance between fixing bugs and not</div><div>regressing, with a higher priority on not regressing. However we if we can't</div><div>detect we regress, we have to assume we don't, as we'd otherwise be unable</div><div>to even make any releases.</div><div><br></div><div>I'd be happy to discuss this further, and setup some nix based test harness for</div><div>this, as time permits (with windows test being run through some cross compilation</div><div>and wine based) setup.</div><div><br></div><div>Cheers, </div><div> Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 15, 2020 at 3:31 PM Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there!<br>
<br>
Thanks everyone for showing interest. I've started a wiki page here:<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers</a><br>
Please add yourself to the release you'd like to maintain. I've tried<br>
to come up with a plan on how to actually look at this problem,<br>
and it appears to me that we want a list of Merge Requests that are<br>
considered for backporting, and then see to which GHC we<br>
backport them. So essentially a matrix with GHC releases / merge<br>
requests, and values being either empty or the commit in which<br>
the MR was backported.<br>
<br>
To get the existing matrix we might try to extract this from the git<br>
history? Does anyone have a good idea how to do this properly?<br>
The alternative would be to go through all existing MRs, and check for<br>
backports, which would be quite tedious, and an automated<br>
solution (at least to get the initial matrix would be good?). In<br>
general I believe there to be value in a matrix of backports for easy<br>
lookup.<br>
<br>
Then we'll need a good way to flag new incoming MRs for backports, and<br>
have the release maintainers look at them, and their<br>
applicability/suitability for a given release.<br>
<br>
Finally, let's not kid ourselves here, this will require some time<br>
investment, taking ownership and coordination. I don't think we need<br>
to rush releases, but we should make sure that releases are of good quality.<br>
<br>
Cheers,<br>
Moritz<br>
<br>
On Tue, Aug 11, 2020 at 11:29 PM Hemanth Kapila <<a href="mailto:saihemanth@gmail.com" target="_blank">saihemanth@gmail.com</a>> wrote:<br>
><br>
> Thanks for the note.<br>
><br>
> I will be happy to pitch in.<br>
><br>
> Thanks,<br>
> Hemanth<br>
><br>
> On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:<br>
>><br>
>> Hi there!<br>
>><br>
>> As it stands right now, Ben is the one who works tirelessly trying to<br>
>> cut releases. Not just for the most recent version, but also for<br>
>> previous versions. Most recently 8.10.2, but we have 9.0 coming up as<br>
>> well.<br>
>><br>
>> I know that there are some people who deeply care for personal or<br>
>> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of<br>
>> them have stacks of patches applied, or proprietary extensions. I'd<br>
>> argue that most of those applied patches are backports of bug fixes<br>
>> and rarely language features, as language features will break<br>
>> compatibility (due to ghc, base, and other library versions anyway).<br>
>><br>
>> I would therefore like drum up a group of people who will take care<br>
>> (ideally 2+ per release) of backporting and making minor partch<br>
>> releases. This does not have to go on forever, but it would take much<br>
>> needed load off of Ben to focus on what ever happens in ghc HEAD.<br>
>><br>
>> So what would this work actually look like? It would consist of<br>
>> - going through the list of MRs and tagging those which are relevant<br>
>> for backporting to a certain release.<br>
>> - backport MRs where the MR does not cleanly apply.<br>
>> - fixup any test-suite failures.<br>
>> - agree on a date to cut/make the release.<br>
>><br>
>> This is not a permanent commitment. I hope we can attract more people<br>
>> to the ghc release managers.<br>
>><br>
>> I'm looking forward to great many responses. And I'm sure Ben will be<br>
>> able to help mentor us through cutting the first releases. I'll<br>
>> volunteer to be part of the 8.6 branch maintainers for now.<br>
>><br>
>> Cheers,<br>
>> Moritz<br>
>><br>
>> PS: There is a slightly related discussion about release cadence and<br>
>> versions and how other projects deal with this in this ticket:<br>
>> <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/18222" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/18222</a><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>