Coordinating the Hadrian merge

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Coordinating the Hadrian merge

Ben Gamari-3
Hi Andrey and Alp,

Before ICFP we concluded that we will merge Hadrian into the GHC tree.
This unfortunately took a back-seat priority-wise while I sorted out
various release things but I think we are now in a position to make this
happen.

Andrey, would you be okay with my merging Hadrian as-is into the GHC
tree? In the past we discussed squashing the project's early history
however I've had very little luck doing this cleanly (primarily due to
the difficulty of rebasing in the presence of merge commits)

After merging there will be a period where we flush the pull request
queue but I don't anticipate this causing much trouble.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Coordinating the Hadrian merge

Andrey Mokhov
Hi Ben,

Yes, I'm fine to merge, but we should make it clear that Hadrian should not be used just yet:

1) It is currently broken due to some recent changes in GHC.

2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left.

3) There are a few usability requests by Simon Marlow that we need to address.

> In the past we discussed squashing the project's early history
> however I've had very little luck doing this cleanly

Ouch, it would be a bit grim to merge all those early commits. On the other hand, I looked at commits at the middle of Hadrian's history and they look quite sensible, just overly fine-grained. So, even if we could somehow squash the early history, that probably wouldn't give us much saving in terms of the commit count -- it would still be more than 1K.

P.S.: Don't forget to switch off commit notifications when you do the merge ;-)

Cheers,
Andrey

-----Original Message-----
From: Ben Gamari [mailto:[hidden email]]
Sent: 15 October 2018 23:14
To: Andrey Mokhov <[hidden email]>; Alp Mestanogullari <[hidden email]>
Cc: GHC developers <[hidden email]>
Subject: Coordinating the Hadrian merge

Hi Andrey and Alp,

Before ICFP we concluded that we will merge Hadrian into the GHC tree.
This unfortunately took a back-seat priority-wise while I sorted out
various release things but I think we are now in a position to make this
happen.

Andrey, would you be okay with my merging Hadrian as-is into the GHC
tree? In the past we discussed squashing the project's early history
however I've had very little luck doing this cleanly (primarily due to
the difficulty of rebasing in the presence of merge commits)

After merging there will be a period where we flush the pull request
queue but I don't anticipate this causing much trouble.

Cheers,

- Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Coordinating the Hadrian merge

Alp Mestanogullari-2
Hello,

Andrey: the hadrian submodule has been around for a while now, yet
people have not exactly abandoned the make build system. Merging hadrian
in the main ghc repo just means turning that submodule into a proper
subdirectory, after all. I might be wrong but I really doubt this will
make much of a difference for most ghc devs and suddenly catch
everyone's attention.

The most important point of merging, in my opinion, once we "unbreak"
hadrian, will be to add at least one hadrian job in CI to make sure that
this (breakage) never happens without us noticing right away, so ideally
before differentials land.

I don't see the merge as "alright, hadrian's ready, let's use it
everyone", it's really about us hadrian contributors not finding the
"catch-up" game all that fun after we've played it dozens of times.
Without all those bumps on the road, who knows where hadrian would be
right now.

On 16/10/2018 01:12, Andrey Mokhov wrote:

> Hi Ben,
>
> Yes, I'm fine to merge, but we should make it clear that Hadrian should not be used just yet:
>
> 1) It is currently broken due to some recent changes in GHC.
>
> 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left.
>
> 3) There are a few usability requests by Simon Marlow that we need to address.
>
>> In the past we discussed squashing the project's early history
>> however I've had very little luck doing this cleanly
> Ouch, it would be a bit grim to merge all those early commits. On the other hand, I looked at commits at the middle of Hadrian's history and they look quite sensible, just overly fine-grained. So, even if we could somehow squash the early history, that probably wouldn't give us much saving in terms of the commit count -- it would still be more than 1K.
>
> P.S.: Don't forget to switch off commit notifications when you do the merge ;-)
>
> Cheers,
> Andrey
>
> -----Original Message-----
> From: Ben Gamari [mailto:[hidden email]]
> Sent: 15 October 2018 23:14
> To: Andrey Mokhov <[hidden email]>; Alp Mestanogullari <[hidden email]>
> Cc: GHC developers <[hidden email]>
> Subject: Coordinating the Hadrian merge
>
> Hi Andrey and Alp,
>
> Before ICFP we concluded that we will merge Hadrian into the GHC tree.
> This unfortunately took a back-seat priority-wise while I sorted out
> various release things but I think we are now in a position to make this
> happen.
>
> Andrey, would you be okay with my merging Hadrian as-is into the GHC
> tree? In the past we discussed squashing the project's early history
> however I've had very little luck doing this cleanly (primarily due to
> the difficulty of rebasing in the presence of merge commits)
>
> After merging there will be a period where we flush the pull request
> queue but I don't anticipate this causing much trouble.
>
> Cheers,
>
> - Ben
>

--
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Coordinating the Hadrian merge

Ben Gamari-3
In reply to this post by Andrey Mokhov
Andrey Mokhov <[hidden email]> writes:

> Hi Ben,
>
> Yes, I'm fine to merge, but we should make it clear that Hadrian
> should not be used just yet:
>
> 1) It is currently broken due to some recent changes in GHC.
>
> 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left.
>
> 3) There are a few usability requests by Simon Marlow that we need to address.
>
>> In the past we discussed squashing the project's early history
>> however I've had very little luck doing this cleanly
>
Sure, I'm happy to make it clear that things are still in flux and that
there are known weaknesses. That being said, I'm not sure it helps to
active discourage use. Afterall, there will be little incentive for
others to help find and fix the remaining issues unless there are users.

> Ouch, it would be a bit grim to merge all those early commits. On the
> other hand, I looked at commits at the middle of Hadrian's history and
> they look quite sensible, just overly fine-grained. So, even if we
> could somehow squash the early history, that probably wouldn't give us
> much saving in terms of the commit count -- it would still be more
> than 1K.
>
Right; given that GHC itself has more than 50k commits I'm not terribly
concerned about Hadrian's contribution.

How should we handle ticket tracking post-merge? The easiest option
would probably be to keep the existing tickets on GitHub and ask that
new tickets be reported via Trac.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Coordinating the Hadrian merge

Andrey Mokhov
Thanks Alp and Ben!

I fully agree with you. Let's go ahead.

Ben: I guess you'll do the actual merge -- feel free to do this whenever you like.

> How should we handle ticket tracking post-merge? The easiest option
> would probably be to keep the existing tickets on GitHub and ask that
> new tickets be reported via Trac.

Yes, this sounds good.

Cheers,
Andrey

-----Original Message-----
From: Ben Gamari [mailto:[hidden email]]
Sent: 16 October 2018 02:33
To: Andrey Mokhov <[hidden email]>; Alp Mestanogullari <[hidden email]>
Cc: GHC developers <[hidden email]>
Subject: RE: Coordinating the Hadrian merge

Andrey Mokhov <[hidden email]> writes:

> Hi Ben,
>
> Yes, I'm fine to merge, but we should make it clear that Hadrian
> should not be used just yet:
>
> 1) It is currently broken due to some recent changes in GHC.
>
> 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left.
>
> 3) There are a few usability requests by Simon Marlow that we need to address.
>
>> In the past we discussed squashing the project's early history
>> however I've had very little luck doing this cleanly
>
Sure, I'm happy to make it clear that things are still in flux and that
there are known weaknesses. That being said, I'm not sure it helps to
active discourage use. Afterall, there will be little incentive for
others to help find and fix the remaining issues unless there are users.

> Ouch, it would be a bit grim to merge all those early commits. On the
> other hand, I looked at commits at the middle of Hadrian's history and
> they look quite sensible, just overly fine-grained. So, even if we
> could somehow squash the early history, that probably wouldn't give us
> much saving in terms of the commit count -- it would still be more
> than 1K.
>
Right; given that GHC itself has more than 50k commits I'm not terribly
concerned about Hadrian's contribution.

How should we handle ticket tracking post-merge? The easiest option
would probably be to keep the existing tickets on GitHub and ask that
new tickets be reported via Trac.

Cheers,

- Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs