I would just point out that decision by committee, and in particular the GHC
Proposals process, has a high cost in terms of both total human brain cycles
and latency. The cost is entirely justified when it comes to things that are a)
hard to revert and b) extremely hard to get right the first time, like new
extensions to the language, or c) very sensitive (like governance, say). For
things like breaking changes to API's, it's worth writing out what the current
problems are. Are users complaining that the API churn is too high? Are they
concerned about endemic quality problems with the API?
It may be enough to make sure to know who the main users of the API are and tag
them as reviewers on these types of changes in GitLab. Or to avoid extra
process but enshrine principles that might be necessary to adopt, like saying
that existing API functions should always be kept as-is during some deprecation
period and new functionality should be exposed in new additions to the API.
Principles to be upheld by reviewers.
On Mon, Jul 27, 2020 at 10:45:50, Simon Peyton Jones < ghc-devs@haskell.org >
wrote:
>
>
>
> A recent MR for GHC (
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3758 ) (adding
> machinery for plugins to write data to extensible interface files) made me
> wonder:
>
>
>
>
> how we should treat significant changes to the GHC API?
>
>
>
>
> Changes to the GHC API, especially to bits used by plugins or by IDEs, are
> clearly user-visible to an important class of users – they are not just
> internal to GHC itself. So, how should we review them? Should they
> perhaps be part of the GHC proposals process? Or some other similar
> process? (The collection of experts on the GHC API, plugins, IDEs etc,
> is rather different to the membership of the GHC steering group.)
>
>
>
>
> I'm asking, not to be obstructive, but because the GHC API deserves to be
> thought of as a whole; in the past it has grown incrementally, without
> much discussion, and that has not served us well. But at the moment there
> is no process, no group to consult.
>
>
>
>
> Any views?
>
>
>
>
> Simon
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@ haskell. org ( ghc-devs@haskell.org )
> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ ghc-devs (
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs )
>
>
>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
