[ghc-steering-committee] GHC2023

[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

  For each of the following extension, should it become part of
>   GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
>

I rather think we should *first *decide on GHC20xx cadence.  Our advertised
cadence is advertised as annual, but my instinct is that's too frequent.
I'd just every 3 yrs, which appears to match Rust.

Can we vote on that first?

Simon


On Sun, 8 Jan 2023 at 19:33, Chris Dornan <chris at chrisdornan.com> wrote:

> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious.
>
>
> Very well put -- count me in. I think the anxiety around us generating
> more things that the community has to think about is understandable, but
> other than that there isn't a great deal of substance to the objections,
> but I think the idea of a steady stream of refinement around what we think
> should be in 'modern base Haskell' is a strong and important one, and a
> steady effort of refinement is I am sure going to lead to a better and more
> rational result than periodic bun fights to determine what is going into
> the next decade of 'modern base Haskell'.
>
> So I vote yes to continuing to think about what we want in ghc2023.
>
> Thanks again Joachim for (again) keeping us on track.
>
> Chris
>
> On 8 Jan 2023, at 10:35, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> Am Mittwoch, dem 23.11.2022 um 17:51 +0100 schrieb Joachim Breitner:
>
> encouraged by Arnaud reports about Rust editions, and also in light of
> the ExplicitNamespaces “bug” in GHC2021, I’m now starting a proposal to
> define GHC2023.
>
> Please see
> https://github.com/ghc-proposals/ghc-proposals/pull/559
>
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>
> The proposal text succinctly tries to alleviate worries that this is
> “too soon”, and gives motivation for the nominated extensions.
>
> At the moment it suggest to add ExplicitNamespaces and LambdaCase
>
> I invite all committee members to
> * nominate more extensions to add
> * bring arguments in favor of an extension
> * bring arguments against an extension
>
> You can either add them directly (via suggested edits) to the proposal
> text, or write them here and I’ll paraphrase them into that document,
> to try to summarize the discussion well.
>
> Once that phase seems concluded, I’ll invite you to vote. Not sure yet
> how precisely, but we’ll vote in a way that one can also express that
> no GHC2023 should happen.
>
>
> I have not seen much engagement from the committee on this PR, and I
> sense a certain reluctance to have another GHC20xx this year. But I
> don’t want us to deviate from the original accepted plan just because
> of implicit assumptions, nor get bogged down by the more fundamental
> (and important!) discussion about the role of extensions in general.
>
> 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.
>
> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious. Even if the delta is kinda small.
> Actually, I should say: _Especially_ if the delta is kinda small! This
> takes the anxiety out of “anew GHC20xx has been released”, just like
> the now bi-yearly GHC releases ideally don’t scare anyone anymore, as
> it helps us get used to and gain practice with the process.
>
> So let’s collect possibly more nominations and otherwise discuss with
> the community on the PR for two more weeks (until roughly Sun, Jan 22).
> If you’d like to get an extension on the ballot, or expand the
> rationale for an extension, simply edit
>
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>
> Then I will ask a for a vote. The ballot will roughly look like this:
>
>  For each of the following extension, should it become part of
>  GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
>
>  GotoStatement
>  SemanticComments
>  ImplementationByChatGTP
>
> We’ll have GHC2023 if _at leas one_ extension has a majority of “strong
> yes” vote, and it will contain those extensions that have a majority of
> “yes” votes.
>
> This allows you to distinguish between “worth having GHC2023 for” from
> “not worth having GHC2023 for, but good enough to include if we have
> GHC2023 anyways”. For example if you think there shouldn’t be a
> GHC2023, you just never vote “strong yes”, but you can still have a say
> what should be in it if it happens, by voting “weak yes” or “no”.
>
>
> Cheers,
> Joachim
>
>
>
>
>
>
> --
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230110/9093fefe/attachment-0001.html>