Re: Plan for GHC 9.2

2021-03-02 Thread Ben Gamari
Ben Gamari  writes:

> tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
>especially if you have something you would like merged for 9.2.1.
>
> Hello all,
>
Hi all,

With the planned fork deadline looming, I thought now would be a good
time for a bit of a status update. As you likely realized, various CI
breakages have resulted in quite a bit of lost merge time over the past
two weeks. As a result, we currently have many, but far from all, of the
patches slated for 9.2 in the tree.

To avoid having a repeat of the very backport-heavy 9.0 series, I am
going to bump back the fork date at least another week to allow the
remaining large bits of work to make it into the tree.

In particular what remains is:

 * Finishing the rework of sized integer primops (#19026, John Ericson)
 * Bumping bytestring to 0.11 (#19091, Ben)
 * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
 * -XGHC2021 (Joachim)
 * Bytecode-from-STG (Luite)
 * Record dot syntax (Shayne)
 * template-haskell putDoc/getDoc (!3330, Luke Lau)
 * UnliftedDataTypes (!2218, Sebastian Graf)
 * ARM NCG backend and further stabilize Apple ARM support? (Moritz)

If you see a project of yours above then do let me know soon if you have
doubts whether you can get it into a mergeable state this week.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


RE: Plan for GHC 9.2

2021-02-15 Thread Ben Gamari
Simon Peyton Jones via ghc-devs  writes:

> Ben
>
> Can we get record dot syntax into 9.2?
>
> * Shayne is really nearly there in !4532; he has been working
>   hard and recently.

Yes, Shayne asked about this last week; I updated the milestone and
added it to the milestone highlights [1].

> * It depends on my !4981 (was 4722) which fixes some bugs and
>   I'm keen to commit.
>
Alright, let's add it 

>
> So, is it ok in principle to pull to trigger on !4981, and hopefully !4532?
Yes, I've added !4981 to the merge queue. !4532 can be merged whenever
it is ready.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Plan for GHC 9.2

2021-02-15 Thread Adam Gundry
[Re-sending from the correct address, apologies!]

It would be great to get RecordDotSyntax for selection into 9.2.

As I just commented on !4532 [1] there's one awkward point to resolve,
which is that 9.2 will probably not have `setField`, on which
RecordDotSyntax updates depend.

Cheers,

Adam

[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4532#note_330581)


On 15/02/2021 10:33, Simon Peyton Jones via ghc-devs wrote:
> Ben
> 
> Can we get record dot syntax into 9.2?
> 
> * Shayne is really nearly there in !4532; he has been working
>   hard and recently.
> * It depends on my !4981 (was 4722) which fixes some bugs and
>   I'm keen to commit.
> 
> 
> So, is it ok in principle to pull to trigger on !4981, and hopefully !4532?
> 
> Simon
> 
> |  -Original Message-
> |  From: ghc-devs  On Behalf Of Ben Gamari
> |  Sent: 04 February 2021 18:56
> |  To: GHC developers 
> |  Subject: Plan for GHC 9.2
> |  
> |  
> |  tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
> | especially if you have something you would like merged for
> |  9.2.1.
> |  
> |  Hello all,
> |  
> |  With GHC 9.0.1 at long-last out the door, it is time that we start
> |  turning attention to GHC 9.2. I would like to avoid making the mistake
> |  made in the 9.0 series in starting the fork in a state that required a
> |  significant amount of backporting to be releaseable. Consequently, I
> |  want to make sure that we have a fork schedule that is realistic given
> |  the things that need to be merged for 9.2. These include:
> |  
> |   * Update haddock submodule in `master` (Ben)
> |   * Bumping bytestring to 0.11 (#19091, Ben)
> |   * Finishing the rework of sized integer primops (#19026, John
> |  Ericson)
> |   * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
> |   * Merge BoxedRep (#17526, Ben)
> |   * ARM NCG backend and further stabilize Apple ARM support? (Moritz)
> |   * Some form of coercion zapping (Ben, Simon, Richard)
> |   * Tag inference analysis and tag check elision (Andreas)
> |  
> |  If you see something that you would like to see in 9.2.1 please do
> |  holler. Otherwise, if you see your name in this list it would be great
> |  if you could let me know when you think your project may be in a
> |  mergeable state.
> |  
> |  Ideally we would strive for a schedule like the following:
> |  
> |  4 February 2021:   We are here
> | ~4 weeks pass
> |  3 March 2021:  Release branch forked
> | 1 week passes
> |  10 March 2021: Alpha 1 released
> | 3 weeks pass
> |  31 March 2021: Alpha 2 released
> | 2 weeks pass
> |  14 April 2021: Alpha 3 released
> | 2 weeks pass
> |  28 April 2021: Alpha 4 released
> | 1 week passes
> |  5 May 2021:Beta 1 released
> | 1 week passes
> |  12 May 2021:   Release candidate 1 released
> | 2 weeks pass
> |  26 May 2021:   Final release
> |  
> |  This provides ample time for stabilization while avoiding deviation
> |  from the usual May release timeframe. However, this would require that
> |  we move aggressively to start getting the tree into shape since the
> |  fork would be less than four weeks away. I would appreciate
> |  contributors'
> |  thoughts on the viability of this timeline.
> |  
> |  Cheers,
> |  
> |  - Ben


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


RE: Plan for GHC 9.2

2021-02-15 Thread Simon Peyton Jones via ghc-devs
Ben

Can we get record dot syntax into 9.2?

* Shayne is really nearly there in !4532; he has been working
  hard and recently.
* It depends on my !4981 (was 4722) which fixes some bugs and
  I'm keen to commit.


So, is it ok in principle to pull to trigger on !4981, and hopefully !4532?

Simon

|  -Original Message-
|  From: ghc-devs  On Behalf Of Ben Gamari
|  Sent: 04 February 2021 18:56
|  To: GHC developers 
|  Subject: Plan for GHC 9.2
|  
|  
|  tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
| especially if you have something you would like merged for
|  9.2.1.
|  
|  Hello all,
|  
|  With GHC 9.0.1 at long-last out the door, it is time that we start
|  turning attention to GHC 9.2. I would like to avoid making the mistake
|  made in the 9.0 series in starting the fork in a state that required a
|  significant amount of backporting to be releaseable. Consequently, I
|  want to make sure that we have a fork schedule that is realistic given
|  the things that need to be merged for 9.2. These include:
|  
|   * Update haddock submodule in `master` (Ben)
|   * Bumping bytestring to 0.11 (#19091, Ben)
|   * Finishing the rework of sized integer primops (#19026, John
|  Ericson)
|   * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
|   * Merge BoxedRep (#17526, Ben)
|   * ARM NCG backend and further stabilize Apple ARM support? (Moritz)
|   * Some form of coercion zapping (Ben, Simon, Richard)
|   * Tag inference analysis and tag check elision (Andreas)
|  
|  If you see something that you would like to see in 9.2.1 please do
|  holler. Otherwise, if you see your name in this list it would be great
|  if you could let me know when you think your project may be in a
|  mergeable state.
|  
|  Ideally we would strive for a schedule like the following:
|  
|  4 February 2021:   We are here
| ~4 weeks pass
|  3 March 2021:  Release branch forked
| 1 week passes
|  10 March 2021: Alpha 1 released
| 3 weeks pass
|  31 March 2021: Alpha 2 released
| 2 weeks pass
|  14 April 2021: Alpha 3 released
| 2 weeks pass
|  28 April 2021: Alpha 4 released
| 1 week passes
|  5 May 2021:Beta 1 released
| 1 week passes
|  12 May 2021:   Release candidate 1 released
| 2 weeks pass
|  26 May 2021:   Final release
|  
|  This provides ample time for stabilization while avoiding deviation
|  from the usual May release timeframe. However, this would require that
|  we move aggressively to start getting the tree into shape since the
|  fork would be less than four weeks away. I would appreciate
|  contributors'
|  thoughts on the viability of this timeline.
|  
|  Cheers,
|  
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


RE: Plan for GHC 9.2

2021-02-11 Thread Ben Gamari
Simon Peyton Jones via ghc-devs  writes:

> Yes I agree, unlifted data types would be terrific.
>
> From: ghc-devs  On Behalf Of Sebastian Graf
> Sent: 11 February 2021 10:25
> To: Ben Gamari 
> Cc: ghc-devs 
> Subject: Re: Plan for GHC 9.2
>
> Hi,
>
> Since my hopes of finally merging Nested CPR have recently been crushed 
> again, I hope that we can include the implementation of the UnliftedDatatypes 
> extension 
> (proposal<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0265-unlifted-datatypes.rst=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556220696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=RtIcZVbhIhqLo2KvXzUME5alwqQM7pI2e2dTLFGSGkI%3D=0>,
>  
> implementation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F2218=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556230694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=71V9d0KIbAjVD5h9B6ZtmO%2FCDpFI3ZtcfOBt5%2BTUEeY%3D=0>).
> It was on ice since it depends on the BoxedRep proposal, but if
> BoxedRep is going to make it, surely UnliftedDatatypes can make it,
> too.
>
> I expect quite a few bugs, simply because I don't have much code to
> test it on yet. But I'm very confident that existing code isn't
> impacted by that, as most of the functionality (CodeGen for unlifted
> types, most importantly) was already there and I only had to refine a
> conditional here and there.
>
It would indeed be very exciting to finally have UnliftedDataTypes. If
things turn out to be non-trivial then I think we should open to letting
it slide for 9.4, but otherwise I am open to merging for 9.2 if a patch
appeared.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


RE: Plan for GHC 9.2

2021-02-11 Thread Simon Peyton Jones via ghc-devs
Yes I agree, unlifted data types would be terrific.

From: ghc-devs  On Behalf Of Sebastian Graf
Sent: 11 February 2021 10:25
To: Ben Gamari 
Cc: ghc-devs 
Subject: Re: Plan for GHC 9.2

Hi,

Since my hopes of finally merging Nested CPR have recently been crushed again, 
I hope that we can include the implementation of the UnliftedDatatypes 
extension 
(proposal<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0265-unlifted-datatypes.rst=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556220696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=RtIcZVbhIhqLo2KvXzUME5alwqQM7pI2e2dTLFGSGkI%3D=0>,
 
implementation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F2218=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556230694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=71V9d0KIbAjVD5h9B6ZtmO%2FCDpFI3ZtcfOBt5%2BTUEeY%3D=0>).
It was on ice since it depends on the BoxedRep proposal, but if BoxedRep is 
going to make it, surely UnliftedDatatypes can make it, too.
I expect quite a few bugs, simply because I don't have much code to test it on 
yet. But I'm very confident that existing code isn't impacted by that, as most 
of the functionality (CodeGen for unlifted types, most importantly) was already 
there and I only had to refine a conditional here and there.

Cheers,
Sebastian

Am Mi., 10. Feb. 2021 um 18:42 Uhr schrieb Ben Gamari 
mailto:b...@well-typed.com>>:
Roland Senn mailto:r...@bluewin.ch>> writes:

> I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi
> debugger it adds the possibility to set ignore counts to breakpoints.
> The next  times the break point is reached the program's
> execution does not stop. This feature is available in nearly every
> debugger, but until now not yet in the GHCi debugger.
> Merge request !4839 is ready for review  (and it's NOT rocket
> science...)
>
Indeed, this seems quite reasonable. I don't see any reason why we
shouldn't be able to get it in to 9.2.1.

Cheers,

- Ben

___
ghc-devs mailing list
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556230694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=EFDeNDiYSopZSvolBGHSU0cdCdv%2Fc53xA1M4gBTth0M%3D=0>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Plan for GHC 9.2

2021-02-11 Thread Sebastian Graf
Hi,

Since my hopes of finally merging Nested CPR have recently been crushed
again, I hope that we can include the implementation of the
UnliftedDatatypes extension (proposal
,
implementation ).
It was on ice since it depends on the BoxedRep proposal, but if BoxedRep is
going to make it, surely UnliftedDatatypes can make it, too.
I expect quite a few bugs, simply because I don't have much code to test it
on yet. But I'm very confident that existing code isn't impacted by that,
as most of the functionality (CodeGen for unlifted types, most importantly)
was already there and I only had to refine a conditional here and there.

Cheers,
Sebastian

Am Mi., 10. Feb. 2021 um 18:42 Uhr schrieb Ben Gamari :

> Roland Senn  writes:
>
> > I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi
> > debugger it adds the possibility to set ignore counts to breakpoints.
> > The next  times the break point is reached the program's
> > execution does not stop. This feature is available in nearly every
> > debugger, but until now not yet in the GHCi debugger.
> > Merge request !4839 is ready for review  (and it's NOT rocket
> > science...)
> >
> Indeed, this seems quite reasonable. I don't see any reason why we
> shouldn't be able to get it in to 9.2.1.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> 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


Re: Plan for GHC 9.2

2021-02-10 Thread Ben Gamari
Roland Senn  writes:

> I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi
> debugger it adds the possibility to set ignore counts to breakpoints.
> The next  times the break point is reached the program's
> execution does not stop. This feature is available in nearly every
> debugger, but until now not yet in the GHCi debugger.
> Merge request !4839 is ready for review  (and it's NOT rocket
> science...) 
>
Indeed, this seems quite reasonable. I don't see any reason why we
shouldn't be able to get it in to 9.2.1.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Plan for GHC 9.2

2021-02-10 Thread Roland Senn
I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi
debugger it adds the possibility to set ignore counts to breakpoints.
The next  times the break point is reached the program's
execution does not stop. This feature is available in nearly every
debugger, but until now not yet in the GHCi debugger.
Merge request !4839 is ready for review  (and it's NOT rocket
science...) 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Plan for GHC 9.2

2021-02-09 Thread Matthew Pickering
My patch adding `-finfo-table-map` and `-fdistinct-constructor-tables`
is ready to review and should be included in 9.2.
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3469

There are also a one outstanding patches related to ghc-debug.
(https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4583)

Cheers,

Matt

On Thu, Feb 4, 2021 at 6:56 PM Ben Gamari  wrote:
>
>
> tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
>especially if you have something you would like merged for 9.2.1.
>
> Hello all,
>
> With GHC 9.0.1 at long-last out the door, it is time that we start
> turning attention to GHC 9.2. I would like to avoid making the mistake
> made in the 9.0 series in starting the fork in a state that required a
> significant amount of backporting to be releaseable. Consequently, I
> want to make sure that we have a fork schedule that is realistic given
> the things that need to be merged for 9.2. These include:
>
>  * Update haddock submodule in `master` (Ben)
>  * Bumping bytestring to 0.11 (#19091, Ben)
>  * Finishing the rework of sized integer primops (#19026, John Ericson)
>  * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
>  * Merge BoxedRep (#17526, Ben)
>  * ARM NCG backend and further stabilize Apple ARM support? (Moritz)
>  * Some form of coercion zapping (Ben, Simon, Richard)
>  * Tag inference analysis and tag check elision (Andreas)
>
> If you see something that you would like to see in 9.2.1 please do
> holler. Otherwise, if you see your name in this list it would be great
> if you could let me know when you think your project may be in a
> mergeable state.
>
> Ideally we would strive for a schedule like the following:
>
> 4 February 2021:   We are here
>~4 weeks pass
> 3 March 2021:  Release branch forked
>1 week passes
> 10 March 2021: Alpha 1 released
>3 weeks pass
> 31 March 2021: Alpha 2 released
>2 weeks pass
> 14 April 2021: Alpha 3 released
>2 weeks pass
> 28 April 2021: Alpha 4 released
>1 week passes
> 5 May 2021:Beta 1 released
>1 week passes
> 12 May 2021:   Release candidate 1 released
>2 weeks pass
> 26 May 2021:   Final release
>
> This provides ample time for stabilization while avoiding deviation from
> the usual May release timeframe. However, this would require that we
> move aggressively to start getting the tree into shape since the fork
> would be less than four weeks away. I would appreciate contributors'
> thoughts on the viability of this timeline.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> 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


Re: Plan for GHC 9.2

2021-02-09 Thread Andrzej Rybczak

Hey Ben,

It would be excellent to get NoFieldSelectors extension 
(https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4743) in.


IIUC it's almost ready to be merged.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Plan for GHC 9.2

2021-02-04 Thread Joachim Breitner
Hi,

Am Donnerstag, den 04.02.2021, 13:56 -0500 schrieb Ben Gamari:
> If you see something that you would like to see in 9.2.1 please do
> holler.

it’s hopefully not big deal technically, but support for GHC2021 would
be desirable. There is a MR

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4853 that “just”
needs chaising test suite failures when rebasing on latest master (and
I’d be grateful if someone more fluent with today’s GHC development
than me would take the MR over at this point)

Cheers,
Joachim

-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Plan for GHC 9.2

2021-02-04 Thread Sebastian Graf
Hi Ben,

Since part of the changes of
https://gitlab.haskell.org/ghc/ghc/-/issues/14422 are already merged into
master (e.g. we ignore the "type signature" part of a COMPLETE sig now,
because there is nothing to disambiguate), it would be good if we merged
the solution outlined in
https://gitlab.haskell.org/ghc/ghc/-/issues/14422#note_321645, as that
would allow users to switch to a new, better mechanism instead of
discovering that COMPLETE signatures seemingly have been ripped of a
feature.
The problem with that is that it needs a GHC proposal, I think, and that's
not written yet.

Also I hope to merge some efforts in the CPR area before the fork. But
that's quite optional.

Cheers,
Sebastian

Am Do., 4. Feb. 2021 um 19:56 Uhr schrieb Ben Gamari :

>
> tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
>especially if you have something you would like merged for 9.2.1.
>
> Hello all,
>
> With GHC 9.0.1 at long-last out the door, it is time that we start
> turning attention to GHC 9.2. I would like to avoid making the mistake
> made in the 9.0 series in starting the fork in a state that required a
> significant amount of backporting to be releaseable. Consequently, I
> want to make sure that we have a fork schedule that is realistic given
> the things that need to be merged for 9.2. These include:
>
>  * Update haddock submodule in `master` (Ben)
>  * Bumping bytestring to 0.11 (#19091, Ben)
>  * Finishing the rework of sized integer primops (#19026, John Ericson)
>  * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
>  * Merge BoxedRep (#17526, Ben)
>  * ARM NCG backend and further stabilize Apple ARM support? (Moritz)
>  * Some form of coercion zapping (Ben, Simon, Richard)
>  * Tag inference analysis and tag check elision (Andreas)
>
> If you see something that you would like to see in 9.2.1 please do
> holler. Otherwise, if you see your name in this list it would be great
> if you could let me know when you think your project may be in a
> mergeable state.
>
> Ideally we would strive for a schedule like the following:
>
> 4 February 2021:   We are here
>~4 weeks pass
> 3 March 2021:  Release branch forked
>1 week passes
> 10 March 2021: Alpha 1 released
>3 weeks pass
> 31 March 2021: Alpha 2 released
>2 weeks pass
> 14 April 2021: Alpha 3 released
>2 weeks pass
> 28 April 2021: Alpha 4 released
>1 week passes
> 5 May 2021:Beta 1 released
>1 week passes
> 12 May 2021:   Release candidate 1 released
>2 weeks pass
> 26 May 2021:   Final release
>
> This provides ample time for stabilization while avoiding deviation from
> the usual May release timeframe. However, this would require that we
> move aggressively to start getting the tree into shape since the fork
> would be less than four weeks away. I would appreciate contributors'
> thoughts on the viability of this timeline.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> 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