[ghc-steering-committee] GHC 2020
Alejandro Serrano Mena
trupill at gmail.com
Mon Oct 19 14:16:53 UTC 2020
We have 50 answers in just 30 minutes :O
El lun., 19 oct. 2020 a las 16:07, Richard Eisenberg (<rae at richarde.dev>)
escribió:
> 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>) 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> On Behalf Of Joachim Breitner
>> | Sent: 18 October 2020 22:01
>> | To: 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
>> | b.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-
>> | ghc-
>> | 2020.md&data=04%7C01%7Csimonpj%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
>> |
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>> | achim-
>> | breitner.de%2F&data=04%7C01%7Csimonpj%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
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> .
>> | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> | committee&data=04%7C01%7Csimonpj%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
>> 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/ff51718b/attachment-0001.html>
More information about the ghc-steering-committee
mailing list