Call for GHC Maintainers

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

Call for GHC Maintainers

Moritz Angermann-2
Hi there!

As it stands right now, Ben is the one who works tirelessly trying to
cut releases. Not just for the most recent version, but also for
previous versions. Most recently 8.10.2, but we have 9.0 coming up as
well.

I know that there are some people who deeply care for personal or
professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
them have stacks of patches applied, or proprietary extensions. I'd
argue that most of those applied patches are backports of bug fixes
and rarely language features, as language features will break
compatibility (due to ghc, base, and other library versions anyway).

I would therefore like drum up a group of people who will take care
(ideally 2+ per release) of backporting and making minor partch
releases. This does not have to go on forever, but it would take much
needed load off of Ben to focus on what ever happens in ghc HEAD.

So what would this work actually look like? It would consist of
- going through the list of MRs and tagging those which are relevant
for backporting to a certain release.
- backport MRs where the MR does not cleanly apply.
- fixup any test-suite failures.
- agree on a date to cut/make the release.

This is not a permanent commitment. I hope we can attract more people
to the ghc release managers.

I'm looking forward to great many responses. And I'm sure Ben will be
able to help mentor us through cutting the first releases. I'll
volunteer to be part of the 8.6 branch maintainers for now.

Cheers,
 Moritz

PS: There is a slightly related discussion about release cadence and
versions and how other projects deal with this in this ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/18222
_______________________________________________
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: Call for GHC Maintainers

Herbert Valerio Riedel
Moritz,

Moritz Angermann <[hidden email]> writes:
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of

You skipped GHC 8.2 ;-)

In any way, I'd be interested in helping making GHC 8.2.3+ happen!

Cheers,
Herbert

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

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

Re: Call for GHC Maintainers

Takenobu Tani
In reply to this post by Moritz Angermann-2
Hi,

I always appreciate maintainers' hard works.

I'd like to support GHC releases and some tasks.
Is there anything that I could do?

PS
My haskell time is limited to nights and weekends, so my works are slow.
(I can't access to haskell community in the day job...)

Regards,
Takenobu

On Tue, Aug 11, 2020 at 11:10 AM Moritz Angermann
<[hidden email]> wrote:

>
> Hi there!
>
> As it stands right now, Ben is the one who works tirelessly trying to
> cut releases. Not just for the most recent version, but also for
> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
> well.
>
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
> them have stacks of patches applied, or proprietary extensions. I'd
> argue that most of those applied patches are backports of bug fixes
> and rarely language features, as language features will break
> compatibility (due to ghc, base, and other library versions anyway).
>
> I would therefore like drum up a group of people who will take care
> (ideally 2+ per release) of backporting and making minor partch
> releases. This does not have to go on forever, but it would take much
> needed load off of Ben to focus on what ever happens in ghc HEAD.
>
> So what would this work actually look like? It would consist of
> - going through the list of MRs and tagging those which are relevant
> for backporting to a certain release.
> - backport MRs where the MR does not cleanly apply.
> - fixup any test-suite failures.
> - agree on a date to cut/make the release.
>
> This is not a permanent commitment. I hope we can attract more people
> to the ghc release managers.
>
> I'm looking forward to great many responses. And I'm sure Ben will be
> able to help mentor us through cutting the first releases. I'll
> volunteer to be part of the 8.6 branch maintainers for now.
>
> Cheers,
>  Moritz
>
> PS: There is a slightly related discussion about release cadence and
> versions and how other projects deal with this in this ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
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: Call for GHC Maintainers

Artem Pelenitsyn
In reply to this post by Moritz Angermann-2
Hello devs,

I may be under-qualified for this sort of task but I’d be happy to pitch in if you find it useful.

Best regards,
Artem Pelenitsyn

On Mon, Aug 10, 2020 at 10:10 PM Moritz Angermann <[hidden email]> wrote:
Hi there!

As it stands right now, Ben is the one who works tirelessly trying to
cut releases. Not just for the most recent version, but also for
previous versions. Most recently 8.10.2, but we have 9.0 coming up as
well.

I know that there are some people who deeply care for personal or
professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
them have stacks of patches applied, or proprietary extensions. I'd
argue that most of those applied patches are backports of bug fixes
and rarely language features, as language features will break
compatibility (due to ghc, base, and other library versions anyway).

I would therefore like drum up a group of people who will take care
(ideally 2+ per release) of backporting and making minor partch
releases. This does not have to go on forever, but it would take much
needed load off of Ben to focus on what ever happens in ghc HEAD.

So what would this work actually look like? It would consist of
- going through the list of MRs and tagging those which are relevant
for backporting to a certain release.
- backport MRs where the MR does not cleanly apply.
- fixup any test-suite failures.
- agree on a date to cut/make the release.

This is not a permanent commitment. I hope we can attract more people
to the ghc release managers.

I'm looking forward to great many responses. And I'm sure Ben will be
able to help mentor us through cutting the first releases. I'll
volunteer to be part of the 8.6 branch maintainers for now.

Cheers,
 Moritz

PS: There is a slightly related discussion about release cadence and
versions and how other projects deal with this in this ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/18222
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
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: Call for GHC Maintainers

Sai Hemanth K
In reply to this post by Moritz Angermann-2
Thanks for the note.

I will be happy to pitch in. 

Thanks,
Hemanth

On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <[hidden email]> wrote:
Hi there!

As it stands right now, Ben is the one who works tirelessly trying to
cut releases. Not just for the most recent version, but also for
previous versions. Most recently 8.10.2, but we have 9.0 coming up as
well.

I know that there are some people who deeply care for personal or
professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
them have stacks of patches applied, or proprietary extensions. I'd
argue that most of those applied patches are backports of bug fixes
and rarely language features, as language features will break
compatibility (due to ghc, base, and other library versions anyway).

I would therefore like drum up a group of people who will take care
(ideally 2+ per release) of backporting and making minor partch
releases. This does not have to go on forever, but it would take much
needed load off of Ben to focus on what ever happens in ghc HEAD.

So what would this work actually look like? It would consist of
- going through the list of MRs and tagging those which are relevant
for backporting to a certain release.
- backport MRs where the MR does not cleanly apply.
- fixup any test-suite failures.
- agree on a date to cut/make the release.

This is not a permanent commitment. I hope we can attract more people
to the ghc release managers.

I'm looking forward to great many responses. And I'm sure Ben will be
able to help mentor us through cutting the first releases. I'll
volunteer to be part of the 8.6 branch maintainers for now.

Cheers,
 Moritz

PS: There is a slightly related discussion about release cadence and
versions and how other projects deal with this in this ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/18222
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
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: Call for GHC Maintainers

Moritz Angermann-2
Hi there!

Thanks everyone for showing interest. I've started a wiki page here:
https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers
Please add yourself to the release you'd like to maintain. I've tried
to come up with a plan on how to actually look at this problem,
and it appears to me that we want a list of Merge Requests that are
considered for backporting, and then see to which GHC we
backport them.  So essentially a matrix with GHC releases / merge
requests, and values being either empty or the commit in which
the MR was backported.

To get the existing matrix we might try to extract this from the git
history? Does anyone have a good idea how to do this properly?
The alternative would be to go through all existing MRs, and check for
backports, which would be quite tedious, and an automated
solution (at least to get the initial matrix would be good?).  In
general I believe there to be value in a matrix of backports for easy
lookup.

Then we'll need a good way to flag new incoming MRs for backports, and
have the release maintainers look at them, and their
applicability/suitability for a given release.

Finally, let's not kid ourselves here, this will require some time
investment, taking ownership and coordination. I don't think we need
to rush releases, but we should make sure that releases are of good quality.

Cheers,
 Moritz

On Tue, Aug 11, 2020 at 11:29 PM Hemanth Kapila <[hidden email]> wrote:

>
> Thanks for the note.
>
> I will be happy to pitch in.
>
> Thanks,
> Hemanth
>
> On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <[hidden email]> wrote:
>>
>> Hi there!
>>
>> As it stands right now, Ben is the one who works tirelessly trying to
>> cut releases. Not just for the most recent version, but also for
>> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
>> well.
>>
>> I know that there are some people who deeply care for personal or
>> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
>> them have stacks of patches applied, or proprietary extensions. I'd
>> argue that most of those applied patches are backports of bug fixes
>> and rarely language features, as language features will break
>> compatibility (due to ghc, base, and other library versions anyway).
>>
>> I would therefore like drum up a group of people who will take care
>> (ideally 2+ per release) of backporting and making minor partch
>> releases. This does not have to go on forever, but it would take much
>> needed load off of Ben to focus on what ever happens in ghc HEAD.
>>
>> So what would this work actually look like? It would consist of
>> - going through the list of MRs and tagging those which are relevant
>> for backporting to a certain release.
>> - backport MRs where the MR does not cleanly apply.
>> - fixup any test-suite failures.
>> - agree on a date to cut/make the release.
>>
>> This is not a permanent commitment. I hope we can attract more people
>> to the ghc release managers.
>>
>> I'm looking forward to great many responses. And I'm sure Ben will be
>> able to help mentor us through cutting the first releases. I'll
>> volunteer to be part of the 8.6 branch maintainers for now.
>>
>> Cheers,
>>  Moritz
>>
>> PS: There is a slightly related discussion about release cadence and
>> versions and how other projects deal with this in this ticket:
>> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
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: Call for GHC Maintainers

Moritz Angermann-2
Hi there!

So a few more discussions have come up.  And they have mainly centered
around the question of quality assurance.  Cutting GHC releases is time
consuming and not trivial.  And those people would need to take ownership
of those releases and stand by them.  How do we ensure that backports do
not inadvertently break working compiler?  I'm completely against preventing
new contributors to help with making releases on the ground that things can
go wrong.  This would inevitably just end up preventing people form even
trying, and how do you get good at something if you can't even try to get good
at it?

So the question then is: what can we do to improve/ensure quality of releases?
We certainly have the test-suite, but that might have holes, and backporting the
test-suite will only work so far. Language features that change stdout/stderr
will inevitably be fixed in newer test-suites to accomodate newer compilers, but
will not work with older compilers.

However, we have a large body of public libraries on hackage.  And a curated
set of packages per compiler in the form Stackage LTS sets.  We have something
slightly similar for HEAD with the hackage head overlay.  For older compilers
we can rely on something more mature!

Thus, if we can build some automation to test a compiler against an existing set
of packages, and run their test-suites. There will inevitably be failures, but we'd
be interested in looking at the drivitive only anyway. If the same set of tests fail
that previous compilers failed at, I don't think that should be much of concern. If
fewer tests fail, it would indicate something might have been fixed, or the test
now surfaces some new behaviour that we might want to look at.  Worst case
would be new test that fail, but didn't before.  This should raise red flags and
either have a *very* good argument for why the backport is still the right thing to
do and the test-failures are actually faulty tests, or the backport should just not
be performed.

In the end it will be about striking a balance between fixing bugs and not
regressing, with a higher priority on not regressing.  However we if we can't
detect we regress, we have to assume we don't, as we'd otherwise be unable
to even make any releases.

I'd be happy to discuss this further, and setup some nix based test harness for
this, as time permits (with windows test being run through some cross compilation
and wine based) setup.

Cheers, 
 Moritz

On Sat, Aug 15, 2020 at 3:31 PM Moritz Angermann <[hidden email]> wrote:
Hi there!

Thanks everyone for showing interest. I've started a wiki page here:
https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers
Please add yourself to the release you'd like to maintain. I've tried
to come up with a plan on how to actually look at this problem,
and it appears to me that we want a list of Merge Requests that are
considered for backporting, and then see to which GHC we
backport them.  So essentially a matrix with GHC releases / merge
requests, and values being either empty or the commit in which
the MR was backported.

To get the existing matrix we might try to extract this from the git
history? Does anyone have a good idea how to do this properly?
The alternative would be to go through all existing MRs, and check for
backports, which would be quite tedious, and an automated
solution (at least to get the initial matrix would be good?).  In
general I believe there to be value in a matrix of backports for easy
lookup.

Then we'll need a good way to flag new incoming MRs for backports, and
have the release maintainers look at them, and their
applicability/suitability for a given release.

Finally, let's not kid ourselves here, this will require some time
investment, taking ownership and coordination. I don't think we need
to rush releases, but we should make sure that releases are of good quality.

Cheers,
 Moritz

On Tue, Aug 11, 2020 at 11:29 PM Hemanth Kapila <[hidden email]> wrote:
>
> Thanks for the note.
>
> I will be happy to pitch in.
>
> Thanks,
> Hemanth
>
> On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <[hidden email]> wrote:
>>
>> Hi there!
>>
>> As it stands right now, Ben is the one who works tirelessly trying to
>> cut releases. Not just for the most recent version, but also for
>> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
>> well.
>>
>> I know that there are some people who deeply care for personal or
>> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
>> them have stacks of patches applied, or proprietary extensions. I'd
>> argue that most of those applied patches are backports of bug fixes
>> and rarely language features, as language features will break
>> compatibility (due to ghc, base, and other library versions anyway).
>>
>> I would therefore like drum up a group of people who will take care
>> (ideally 2+ per release) of backporting and making minor partch
>> releases. This does not have to go on forever, but it would take much
>> needed load off of Ben to focus on what ever happens in ghc HEAD.
>>
>> So what would this work actually look like? It would consist of
>> - going through the list of MRs and tagging those which are relevant
>> for backporting to a certain release.
>> - backport MRs where the MR does not cleanly apply.
>> - fixup any test-suite failures.
>> - agree on a date to cut/make the release.
>>
>> This is not a permanent commitment. I hope we can attract more people
>> to the ghc release managers.
>>
>> I'm looking forward to great many responses. And I'm sure Ben will be
>> able to help mentor us through cutting the first releases. I'll
>> volunteer to be part of the 8.6 branch maintainers for now.
>>
>> Cheers,
>>  Moritz
>>
>> PS: There is a slightly related discussion about release cadence and
>> versions and how other projects deal with this in this ticket:
>> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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