Re: haskell/bytestring stalled?

[Simon Jakobi]

I'm also CC'ing the core libraries committee – sorry for not realizing
earlier that they would be interested in this discussion!

Am Do., 19. Dez. 2019 um 17:20 Uhr schrieb Simon Jakobi
<simon....@googlemail.com>:
>
> Hi Herbert,
>
> I apologize for the overly harsh and accusatory tone in my last email.
> After looking through the existing PRs and issues, I was admittedly
> somewhat disappointed over the current situation with bytestring
> issues and PRs, but I shouldn't have expressed my feelings in this
> way.
>
> Also, thanks a lot for responding so quickly today to my many comments
> on issues and PRs.
>
> To be clear, I'm not interested in putting blame on you or Duncan or
> anyone else. I do however strongly believe that bytestring needs a
> more responsive maintainer:
>
> 1. Contributors IMO deserve to get a response within weeks or ideally days.
>
> 2. bytestring users (and that transitively includes all GHC users)
> could benefit massively if some of the current PRs were finally
> merged. For example in [#175], Sylvain Henry reports improvements of
> **11%** for some compilation tasks when he used the PR to build GHC.
>
> And I admittedly don't want to ask you, Herbert, to lead the effort of
> clearing up the maintenance backlog in bytestring. Of course, _any_
> Haskell project you're involved in benefits from your massive
> experience! However, I feel that since your involvement is so crucial
> in so many other essential projects in the Haskell ecosystem, if you
> would shift your focus towards bytestring, these other projects would
> suffer! I also believe that projects like cabal or Hackage need your
> domain knowledge more dearly than bytestring does. So to ask you to
> allocate more time to bytestring, would feel a bit like a zero-sum
> game, or possibly a negative-sum game.
>
> A second, more personal reason, why I would prefer to see a different
> maintainer for bytestring, is your preference for coordinating things
> in private communication. The many PRs and issues in the bytestring
> project, and this email thread demonstrate that there are a lot of
> people who would like to be involved in improving bytestring. Private
> coordination would exclude most of them, and make it more difficult to
> make use of all the help that this project currently needs. I
> understand that your preference for private communication is related
> to your experiences with previous discussions over Haskell projects,
> and I am sorry that it has come so far, but I believe that a more open
> and transparent style of communication is more healthy.
>
> So, while I'm very grateful for your work on bytestring, and while I
> hope that you stay involved in the project, I hope that that someone
> else can take over official maintainer duties.
>
> Now I am not sure who could take on that job. Clearly we need someone
> whom Duncan trusts. That's why I wonder whether someone involved in
> the performance work on GHC could help. Ultimately I don't think that
> their time involvement would need to be very high – good judgment and
> responsiveness seem more important to me. I'm CC'ing the ghc-devs
> list, hoping that someone with the right experience and availability
> would come forward.
>
> Thanks,
> Simon
>
> [#175] https://github.com/haskell/bytestring/pull/175#issuecomment-567233984

[Simon Jakobi]

Hi again, and happy new year! :)

I'd like to revive this thread, now that the holiday season has
passed. Sorry for my somewhat naive attempts to get people involved in
my last emails – I have shortened my CC-list since. :)

I have noticed some healthy activity in the bytestring project in the meantime:

* Duncan suggested in [#198] that GHC 8.10.1 use the existing
bytestring-0.10.10.0 release.

* [#140] has seen more productive discussion on the future of
ByteString's IsString instance, with much valuable input from Herbert.

* At least 3 PRs ([#142], [#196], [#182]) have become ready for merge
(as far as I can tell), although they didn't get a maintainer response
in the last 3 weeks, which I largely attribute to the holidays.

* [#196], which I prepared with the help of Sylvain Henry, fixed the
build of bytestring's benchmark suite which had been broken since 2015
([#52]), and which had been an impediment to many PRs since. This has
allowed me to detect a rather worrying performance regression in GHC
8.10, [#17660].

Many thanks to everyone involved! :)

What remains unclear to me is who will lead the effort of taking care
of bytestring's backlog of open PRs and issues. I still doubt that
Duncan or Herbert have the necessary bandwidth.

Duncan, I would be very grateful if you could share your own
perspective on this in this thread!

Since I had addressed my last email to the CLC, I also wonder about
their perspective on the issue. I have since noticed that bytestring
is in fact not one of the core [libraries] that the CLC officially
maintains. Is the CLC possibly interested in adopting bytestring,
and/or to get involved in improving the maintenance situation in
bytestring? This is just an idea – I don't actually know what power or
resources the CLC could contribute here.

Cheers,
Simon

[#52] https://github.com/haskell/bytestring/issues/52
[#140] https://github.com/haskell/bytestring/issues/140
[#142] https://github.com/haskell/bytestring/pull/142
[#182] https://github.com/haskell/bytestring/pull/182
[#196] https://github.com/haskell/bytestring/pull/196
[#198] https://github.com/haskell/bytestring/issues/198
[#17660] https://gitlab.haskell.org/ghc/ghc/issues/17660
[libraries] https://wiki.haskell.org/Library_submissions#The_Libraries

[George Wilson]

According to this [table], bytestring is a boot library, so by reason
3 listed in [libraries], I believe bytestring already comes under the
CLC. In that case, the latter page should be updated.

It's possible the committee could provide some assistance on the
backlog of issues and PRs. But working on one of the high performance
libraries like bytestring (another example is vector) requires
delicate care, so I think for the most part it would be difficult for
committee members to help in a "drive-by" capacity. I too am
interested in whether Duncan and Herbert would find another maintainer
helpful.

[table] https://gitlab.haskell.org/ghc/ghc/wikis/commentary/libraries/version-history
[libraries] https://wiki.haskell.org/Library_submissions#The_Libraries

Cheers,
George

On Sun, 12 Jan 2020 at 05:07, 'Simon Jakobi' via
haskell-core-libraries <haskell-cor...@googlegroups.com>
wrote:

> --
> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAGtp2Sh8wRp7h-8P6NgVTXc2ytTfu3WARH%2B%2BuMQTND92kjCzQg%40mail.gmail.com.

[Carter Schonwald]

To the extent that hvr the current maintainer wants help from fellow clc, we’re available albeit finite bandwidth.  

Ghc has had a lot of optimizer regressions wrt core libraries for some time now.  The challenge is that the bandwidth etc to straddle both legs is quite a bit of effort! 

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CABzzMawe8_Z18OSZx%2Bff-XNjF_%3DsP5A8gaKQbvtKFWqGUJSSNg%40mail.gmail.com.

[Simon Jakobi]

Am So., 12. Jan. 2020 um 09:32 Uhr schrieb George Wilson <geo...@wils.online>:
>
> According to this [table], bytestring is a boot library, so by reason
> 3 listed in [libraries], I believe bytestring already comes under the
> CLC. In that case, the latter page should be updated.

Thanks George, that's an interesting perspective!

Edward, as the CLC Chair, can you confirm that the CLC in fact
maintains the bytestring library, or clarify what the status of
bytestring in the core libraries is?


> [...] I too am

> interested in whether Duncan and Herbert would find another maintainer
> helpful.

In a brief private email exchange Herbert mentioned that due to
bytestring's critical importance to the ecosystem, Duncan and him
don't want others to make important decisions on bytestring or take
care of the release management.

I think that's rather understandable. IMHO these requirements should
be compatible with some kind of "co-maintainer" role – I have a
similar arrangement with Heinrich Apfelmus regarding the maintenance
of threepenny-gui.

Here's a sketch of what I imagine such a co-maintainer arrangement
could look like in bytestring:

* A co-maintainer cannot upload to Hackage, leaving that to Duncan or Herbert.

* A co-maintainer can merge non-breaking changes – after waiting for a
certain feedback period in the case of user-facing changes.

* A co-maintainer can also help prepare breaking changes and other
important decisions, but would have to leave the final decision to
Duncan, Herbert and, as necessary, the CLC.

IMHO such an arrangement could greatly improve the current situation,
and hopefully allow Herbert and Duncan to focus on the most important
decisions, where their expertise is needed the most.

Herbert, Duncan, what do you think about this idea of a adding a
"co-maintainer"? Would you require any changes to the arrangement to
make it work for you?

Of course, we still need to find one or more good candidates for the
role – is anyone interested?

Cheers,
Simon