[ghc-steering-committee] GHC2023

[Simon Peyton Jones]

>
> That’s part of the vote – just don’t say “strong yes” for any option if
> you think it’s too early. “Strong yes” means “I think there should be a
> GHC2023 because of extension X”.
>

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?

What do other members of the committee think about cadence?  RSVP!  You are
a member!

Simon

On Tue, 10 Jan 2023 at 10:13, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:
> > > So let’s bring this to a vote – if the camp that prefers even rarer
> > > releases is in the majority, the vote will show that.
> > >
> >
> > Well, it will if that's what we vote on, but you are suggesting
> > …
> > Can we vote on that first?
>
> That’s part of the vote – just don’t say “strong yes” for any option if
> you think it’s too early. “Strong yes” means “I think there should be a
> GHC2023 because of extension X”.
> If a majority votes at most “weak yes” to every extension, then there
> will be no GHC2023.
>
> I find a separate vote “should we have GHC2023” is not that meaningful
> if it would be equal to GHC2021 anyways (assuming no extenion gets then
> voted in) so it seems prudent to ask “Is there even any extension that
> warrants having GHC2023.”
>
> >  I'd just every 3 yrs, which appears to match Rust.
>
> I think the comparision is misleading. Rust bundles _breaking_ changes
> every 3 years. Nonbreaking, purely additive, syntax guarded, features
> come out continuously. If we follow their model, we can have GHC20xx
> yearly (or more often!), as long as we hold back _breaking_ changes to
> a three-yearly cadence. (Which seems quite a reasonably policy.)
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230110/573eafdc/attachment.html>