[ghc-steering-committee] GHC 2020
Richard Eisenberg
rae at richarde.dev
Mon Oct 19 14:07:01 UTC 2020
Thanks for pushing this conversation along!
* Though I know I may live to regret it, I think this is a good thing for GHC and for Haskell. My sense (not backed by any real research, of course) is that the community equates (perhaps subconsciously) "this file needs a lot of extensions" with "the code in this file is complicated" -- and thus can conclude that Haskell is a complicated language. This effort helps to reduce this source of negative feelings.
* I prefer not doing this yearly. My vote would be for every 3 years -- but I still prefer doing it yearly over never.
* Polling and data would be fantastic. We can scrape Hackage now, but polling is a function we struggle with.
* I'd like to propose a middle ground between Alejandro's and Joachim's meta-proposals -- mostly because I want more community involvement and ownership than I think Joachim's proposal would allow (my proposal points begin with +; an initial * denotes that we're back to points in this email):
+ Use Alejandro's criteria. (This wasn't stated in Joachim's proposal, but I assume it's true there, too.)
+ From Alejandro: Create a new repo ghc-proposals/ghc-language.
+ From Joachim's proposal: 4 months before the expected GHC spring release day of 202x:
The Secretary starts the GHC202x process. with an email to the list
listing all language extensions supported by GHC that are not in
GHC202(x-1), and asking the committee for “votes” (which are also
nominations).
+ Within two weeks of the start of the process, every committee member is expected to send an initial list of which extensions they expect to be added to GHC20xx to the mailing list. There would *not* be justifications or motivations, just a list.
+ After these two weeks, the Secretary creates a new branch in the ghc-proposals/ghc-language repo, adding a new top-level file named ghc20xx.md (where xx has been instantiated appropriately). This file would contain a list of all the extensions receiving at least 2/3 (rounded up) of the responding members of the committee. (Footnote: I would love to say 2/3 of the committee membership, but history shows that not every committee member will speak up.)
+ The Secretary would then create a PR in ghc-proposals/ghc-language to merge the branch. This PR would state loudly not to comment on individual extensions in the PR.
+ Members of the community would then have 4 weeks to open Issues in the ghc-language repo to discuss individual extensions. Issue titles are required to include the extension name. When conversation reaches general consensus, the Issue would be closed, but memorialized in the ghc20xx.md file with a link to the discussion. If the discussion suggests that an extension *not* be included, that is still memorialized in the file, in a separate section of proposed-but-rejected extensions. (In this paragraph, "general consensus" does not mean unanimity, but a clear preponderance of opinion in one direction.)
+ After four weeks, any extensions still under broad debate would be rejected for inclusion as controversial. The Secretary would move these to the "rejected" section of the .md file with a link to the debate. Debates are encouraged to continue, with the expectation that the resolution of the debate would inform the next GHC20xx process.
+ The Secretary then merges the branch into the ghc-language repo, and the new language is implemented.
+ After another 2 months, any remaining open Issues in the repo are closed, for cleanliness.
* This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's.
* Meta-meta-proposal: Instead of creating competing PRs between these meta-proposals, I propose creating one PR with multiple proposals contained within one file. We can put this in a branch in the main repo (as opposed to the usual habit of putting PRs in a branch on a fork). We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs.
Richard
> On Oct 19, 2020, at 9:21 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
>
> Following Simon's ideas, should we maybe create a poll and some scripts to scrape Hackage/Stackage and inform our decision? For the poll I'm thinking on something like categorizing how much people "want" an extension to be on automatically, ranging from "yes, please!" to "never!". We could even gather a few more opinions about why the choice was made and selecting things like "stability" and so on.
>
> I like Joachim's proposal, if you all agree that pushing this from the Committee would be well-received by the community. I would prefer to have a single PR coming from the community, maybe integrating that proposal with a few points in which we gather input from the community.
>
> Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough, that's 100% fine with me. In fact, my focus is to get the first GHC2020 out. But I think that telling people that there are new chances in a definite period of time helps in giving a mid-term perspective: we don't have to have the perfect set now, we can start and keep refining in the upcoming years.
>
> Regards,
> Alejandro
>
> El lun., 19 oct. 2020 a las 9:22, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>) escribió:
> Some thoughts
>
> * I'm willing, but not truly enthusiastic, about the whole idea.
> The reason I'm willing is because I believe that the community really
> wants it -- but I'd love to have evidence for that belief. This
> discussion is taking place on the GHC committee mailing list to which
> the community more broadly can't easily contribute. I'd love to ask
> them more explicitly, or even take a poll.
>
> * Do we really want to an annual process? My personal thought is
> that every two or three years would be plenty often enough. Having
> a plethora of extensions is confusing. "Is Polykinds in GHC2023?"
>
> * When it comes to individual extensions, I'd like to know what the community
> thinks, since a lot of this is about convenience and stability. I'd
> suggest a poll of Haskell users. Their votes might guide the committee
> -- but would not determine the outcome.
>
> * I would also suggest that the process be informed by a trawl of Hackage/Stackage
> to count how widely used each extension is. That is, seek data as well as opinion.
>
> * Joachim's 2/3 supermajority seems sensible. An extension should only
> make it in if there is solid support.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-
> | bounces at haskell.org <mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
> | Sent: 18 October 2020 22:01
> | To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | Subject: Re: [ghc-steering-committee] GHC 2020
> |
> | Hi,
> |
> | Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena:
> | > I would really like this effort not to die, so I've given the
> | > proposal another push. Following the comments from Simon and Joachim,
> | > I've re-framed the proposal as laying down a process to create new
> | > "language versions" yearly. The idea is to have one of these every
> | > year (or 2, or 3, whatever is decided), coinciding with the spring
> | > release of GHC.
> | >
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu>
> | b.com <http://b.com/>%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-
> | ghc-
> | 2020.md&data=04%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cbdddd9d809644bd069
> | 9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681
> | 5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg
> | pFwJB8wvBxWULqIqFes%3D&reserved=0
> |
> |
> | I like the idea of tying this to the Spring release of GHC, this
> | provides a lot of predictability, and also provides a hard deadline,
> | which makes it more likely to make _some_ progress (instead of never
> | achieving the perfect set of extensions).
> |
> | To questions about the criteria:
> |
> |
> | If GHC2021 contains extension Foo, I assume that by default, GHC2020
> | also contains Foo. But should we allow ourselves to remove something?
> | (I would argue, yes: it should be a rare thing, but if Foo turned out
> | to be problematic, then it seems better to not include it in the next
> | version. Code that still declares 2021 wouldn’t be affected, and code
> | that wants to use GHC2021 and Foo would have to list Foo explicitly,
> | which is arguably a good thing.)
> |
> |
> | Should we make it a hard rule that the extension needs to be supported
> | by the last _n_ versions of GHC?
> | (Would we maybe make point releases of prior versions of GHC to
> | understand -XGHC2021, to make these sets of extensions available to
> | more users faster?)
> |
> |
> | > I think it's important for the community to be involved in the
> | > process. If it's clear that an extension is loved by most of the
> | > community, that's a big plus for acceptance. In addition, if we come
> | > with a list ourselves, we risk having made choices which only show
> | > our (biased) point of view.
> |
> | I would hope that with 10 people on the committee, the bias is not too
> | big. And just like GHC proposals that attract discussions are sent back
> | as “needs review”, extensions that cause non-trivial discussion are, by
> | definition, not uncontroversial enough, and should simply be “maybe
> | next year”.
> |
> | Therefore I would like to start with a slimmer, more effective and
> | efficient process that does not involve a full proposal-size discussion
> | on each extension, and does _not_ cause dozends of parallel discussions
> | with the community. So here is a first draft of the “slim proceess”:
> |
> | =============================================================
> |
> | * 4 months before the expected GHC spring release day of 202x:
> | The Secretary starts the GHC202x process. with an email to the list
> | listing all language extensions supported by GHC that are not in
> | GHC202(x-1), and asking the committee for “votes” (which are also
> | nominations).
> |
> | The secretary also creates a PR with a proposal saying (roughly)
> | > GHC202x contains the following extensions in addition to those
> | > in GHC202(x-1):
> | >
> | > * (none yet)
> |
> | The community may use comments on this PR to weigh in.
> |
> | * Within two weeks of the start of the process,
> | every committee member is expected to send an
> | initial list of which extensions they expect to be in GHC202x
> | to the mailing list. These mails may contain justifications
> | for why a certain extension is or is not included.
> |
> | After these two weeks, the PR is continuously updated by the
> | secretary to reflect the _current_ tally of votes:
> | An extension is included if it is listed by at least ⅔ (rounded up)
> | of committee members.
> |
> | * Within four weeks, of the start of the process,
> | committee members can change their vote (by email to the list).
> |
> | It is absolutely ok to change your mind based on the explanations in
> | the other members’ emails, or the general comments on the PR.
> |
> | * After these four weeks, the proposal with the current tally
> | gets accepted, and defines GHC202x
> |
> | =============================================================
> |
> | The goal here is, of course, to efficiently find out which are the
> | uncontentious extensions, without spending a log of time on the
> | contentious ones (which I think we simply want to continue to guard
> | behind their own explicit extension).
> |
> |
> | Meta-process comments:
> | I’ll turn this into an alternative PR to Alejandro’s once he opened
> | his, and we can vote on both together (using ordered voting, I still
> | prefer Alejandro’s process to no GHC2021, this way we don’t step on
> | each other’s toes).
> |
> |
> |
> | > Since in the first round the possible list of extensions may be quite
> | > big, we might introduce a "fast-lane process" for this one time, for
> | > extensions like EmptyDataDecls or different number formats which seem
> | > to have unanimous support.
> |
> | I guess I agree, and I’d just make that the only process :-)
> |
> | Cheers,
> | Joachim
> | --
> | Joachim Breitner
> | mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> |
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo>
> | achim-
> | breitner.de <http://breitner.de/>%2F&data=04%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cbdddd9d8096
> | 44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> | 86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3csJZH2Ux30FM4OIpLb
> | QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&reserved=0
> |
> |
> | _______________________________________________
> | ghc-steering-committee mailing list
> | ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail>.
> | haskell.org <http://haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&data=04%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cbdddd9d809644bd0
> | 699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516
> | 815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SpEo1OwwBHDb7uIlkgBrnKbL
> | QKwKyWug5dv9Y5coJcQ%3D&reserved=0
> _______________________________________________
> 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>
> _______________________________________________
> 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/20201019/d078c83b/attachment-0001.html>
More information about the ghc-steering-committee
mailing list