<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
That’s part of the vote – just don’t say “strong yes” for any option if<br>
you think it’s too early. “Strong yes” means “I think there should be a<br>
GHC2023 because of extension X”.

</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">It seems a very funny way to do it.  I'd prefer to ask "what cadence do we want" and then move on to discuss features individually.  At the moment I might think "yes, extension X belongs in the next GHC20xx", so do I vote yes or no for X?</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">What do other members of the committee think about cadence?  RSVP!  You are a member!</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 10 Jan 2023 at 10:13, 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:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:<br>
> > So let’s bring this to a vote – if the camp that prefers even rarer<br>
> > releases is in the majority, the vote will show that. <br>
> > <br>
> <br>
> Well, it will if that's what we vote on, but you are suggesting <br>
> …<br>
> Can we vote on that first?<br>
<br>
That’s part of the vote – just don’t say “strong yes” for any option if<br>
you think it’s too early. “Strong yes” means “I think there should be a<br>
GHC2023 because of extension X”.<br>
If a majority votes at most “weak yes” to every extension, then there<br>
will be no GHC2023.<br>
<br>
I find a separate vote “should we have GHC2023” is not that meaningful<br>
if it would be equal to GHC2021 anyways (assuming no extenion gets then<br>
voted in) so it seems prudent to ask “Is there even any extension that<br>
warrants having GHC2023.”<br>
<br>
>  I'd just every 3 yrs, which appears to match Rust.<br>
<br>
I think the comparision is misleading. Rust bundles _breaking_ changes<br>
every 3 years. Nonbreaking, purely additive, syntax guarded, features<br>
come out continuously. If we follow their model, we can have GHC20xx<br>
yearly (or more often!), as long as we hold back _breaking_ changes to<br>
a three-yearly cadence. (Which seems quite a reasonably policy.)<br>
<br>
Cheers,<br>
Joachim<br>
<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>
</blockquote></div>