<div dir="auto"><div>Thanks for the note.</div><div dir="auto"><br></div><div dir="auto">I will be happy to pitch in. </div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Hemanth</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 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" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div>