[ghc-steering-committee] Please review #601: Extension lifecycle, Shepherd: Simon PJ

Fri Aug 25 20:53:06 UTC 2023

I've posted on the proposal. I won't stand in the way of a proposal that has generated positive feedback such as this one, but I worry we've missed the head of the nail here by a little bit. And adopting this proposal has a very real cost, in that it adds another layer of bureaucracy for Haskellers.

Richard

> On Aug 25, 2023, at 3:39 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I'm rather agnostic on the proposal. I'm actually not convinced it solves a real problem for users (though I can see how this categorisation would inform our stance on backward compatibility, so it can be very useful for us steering committee), on the other hand, the proposal seems to be received with a lot of enthusiasm.
> 
> On Thu, 24 Aug 2023 at 22:21, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> I am lukewarm on the proposal. Of course it would be nice to have such
> clear signal. But it’s going to be a lot of work to categorize all
> extensions initially, and then update this categorization as we go.
> Given that even defining a subset of “very stable and mature” (AKA
> GHC20xx) is something that was quite some effort, I am not fully
> optimistic that we’ll be able to deliver.
> 
> But we can at least say we’d like to try, and then see how the
> categorization goes, so yea from me.
> 
> Cheers,
> Joachim
> 
> 
> 
> Am Donnerstag, dem 24.08.2023 um 16:42 +0100 schrieb Simon Peyton
> Jones:
> > Dear GHC steering committee
> > 
> > A month ago I wrote to you concerning GHC Proposal 601 about GHC
> > extensions.
> > 
> > > We propose a categorization scheme for Haskell language extensions.
> > > This scheme is simple, in that there are few categories that are
> > > described in terms of the user-relevant aspects, and it is
> > > actionable, in that it suggests concrete changes to the warning
> > > system of GHC that allow users to express their own risk tolerance
> > > and get guidance as they upgrade their compiler 
> > > 
> > 
> > 
> > It's holiday time I know, but still, I did not get a single reply. 
> > Is that because you all love it or you all hate it?  RSVP!
> > 
> > I propose acceptance, modulo a few clarifications which I have posted
> > on the discussion thread.
> > 
> > Please reply, yea or nay.
> > 
> > Simon
> > 
> > On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> > > Dear GHC Steering Committee
> > > 
> > > Proposal #601 says 
> > > 
> > > We propose a categorization scheme for Haskell language extensions.
> > > This scheme is simple, in that there are few categories that are
> > > described in terms of the user-relevant aspects, and it is
> > > actionable, in that it suggests concrete changes to the warning
> > > system of GHC that allow users to express their own risk tolerance
> > > and get guidance as they upgrade their compiler 
> > > 
> > > I'm happy with this proposal: it seems simple, comprehensible, and
> > > actionable.  
> > > 
> > > The only question in my mind is whether it is worth the bother. 
> > > I'd love to hear from the practitioners on the committee.
> > > 
> > > But I propose that we accept it.
> > > 
> > > Simon
> > > 
> > > 
> > > On Mon, 24 Jul 2023 at 14:39, Joachim Breitner
> > > <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> > > > Dear Committee,
> > > > 
> > > > David Thrane Christiansen suggested to categorize extensions into
> > > > Experimental, Mature, Deprecated and Legacy, and add warning flag
> > > > to
> > > > GHC that allow users to be warned about (or shouted at for) using
> > > > such
> > > > extensions, if they choose so.
> > > > 
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/601 <https://github.com/ghc-proposals/ghc-proposals/pull/601>
> > > > https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>
> > > > 
> > > > Because of the meta-like aspect of this proposal, I’d like to
> > > > assign
> > > > this to Simon PJ.
> > > > 
> > > > 
> > > > Please guide us to a conclusion as outlined in 
> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> > > > 
> > > > 
> > > > Cheers,
> > > > Joachim
> > > > 
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20230825/83d41d30/attachment-0001.html>