Thanks for bringing up this issue, Fumiaki! Your email prompted me to review a few PRs today: * [#155], which hadn't received a review since it it was opened a year and 9 months ago, promptly got new commits from its author, M Farkas-Dyck! :) * In [#151], which promises rather impressive performance improvements, the author Sergey Vinokurov reacted understandably disappointed to my requests for more benchmark results, after his PR had gone unacknowledged for 1 year and 10 months. I think #151 demonstrates how unresponsive maintenance hurts a project – contributors are disappointed by the lack of response and lose their motivation to finish their work. Potential contributors are discouraged when they see that existing PRs aren't getting merged. Moreover, I believe that when core libraries like bytestring get into such a sad state, it hurts the appearance of and users' confidence into the Haskell ecosystem as a whole. I don't blame Herbert or Duncan (CC'd) for not putting more work into bytestring – I'm thankful for all their amazing work for the Haskell ecosystem. But my impression is that both have far more (maintenance and other) responsibilities than available time for unpaid open source work. So I hope that they will allow others to help repair the current situation and get bytestring onto a more sustainable base. I would also like to ask Duncan, the official maintainer, whether he intends to become more active again in this project or whether he might be interested in passing the maintainer hat to someone with more available time for this project. I'm asking because there are at least two PRs that seem to be ready to go, except they're waiting for a review from him: * [#121] has been waiting for his review for 1 year and 10 months. * [#132] has been waiting for his review for at least 1 year and 11 months. Right now I believe it would be good to have a maintainer with the available time to shepherd some new contributors like Fumiaki or me. Since I admittedly don't trust Duncan and Herbert to have that time, I wonder whether someone else, for example from GHC HQ, could get the commit bits. I know that Ben Gamari (CC'd) has requested them for other reasons [1]. It's clear that there are several people interested in helping to maintain and improve bytestring – theindigamer15 (CC'd) offered his help this February in an email that never got an official response [2]. But as long as PRs are unlikely to get merged, there's no point in opening or reviewing one. Cheers, Simon [1] https://mail.haskell.org/pipermail/ghc-devops-group/2019-July/000322.html [2] https://mail.haskell.org/pipermail/haskell-cafe/2019-February/130705.html [#121] https://github.com/haskell/bytestring/pull/121 [#132] https://github.com/haskell/bytestring/pull/132 [#151] https://github.com/haskell/bytestring/pull/151 [#155] https://github.com/haskell/bytestring/pull/155 Am Mi., 18. Dez. 2019 um 10:40 Uhr schrieb Herbert Valerio Riedel :

Hello Fumiaki,

Bytestring is a fundamental library which is used by almost everyone, so its goal is first and foremost to be stable and reliable; hence its maintenance is generally very conservative and slow-paced; it's better this way than to risk introducing regressions. But also, 6 months without visible feedback for a library that's generally considered mature isn't something to be alarmed about either. I for one cycle through the projects I maintain when time permits (usually on weekends) and try to reduce the context switches by working for several hours on a single project, eventually resulting in a new release. This batched mode of operation also means that it takes some time to complete an orbit around all projects and I don't consider this a bad thing; In fact, I don't subscribe to the release early and often poorly paradigm anymore after having exercised it myself as producer as well as experienced it as consumer for a couple decades and I've been burned too many time by careless rushed releases (both by myself as well as others). Maybe I'm just getting older and wiser.

That being said, if you or others want to help out with projects I (co)maintain such as `bytestring`, please get into contact with me. There are things you can do to help with the review of PRs and other tasks that benefit from as many hands or eyes as possible and which would reduce the workload during the focused batch-phase when the careful dedicated release processes is initiated.

-- Herbert

On Wed, Dec 18, 2019 at 9:48 AM Fumiaki Kinoshita wrote:

...

I noticed that issues and PRs on bytestring repository[0] have received no feedback in past 6 months. Does anyone know what's going on? If I can help moving things along, I definitely would like to.

[0] https://github.com/haskell/bytestring _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Hello, I see some activity on GitHub; this strongly motivates me to start doing something concrete! Just looking at the situation, it definitely needs more reviewing - also I'm going to add tests and benchmarks to the pull requests. Given apparent absence of dcoutts, I'm curious we organise this in the future - currently a number of things are blocked on his response. If he's unable to spend time on it for some reason, I think that's much better to have Herbert or someone else as a primary maintainer. 2019年12月19日(木) 16:20 Herbert Valerio Riedel :

Hi Simon,

On Thu, Dec 19, 2019 at 12:43 AM Simon Jakobi wrote:

...

Your email prompted me to review a few PRs today:

Thank you, reviewing PRs is one of the things that definitely helps and what I was hoping for when I wrote

...

That being said, if you or others want to help out with projects I (co)maintain such as `bytestring`, please get into contact with me. There are things you can do to help with the review of PRs and other tasks that benefit from as many hands or eyes as possible and which would reduce the workload during the focused batch-phase when the careful dedicated release processes is initiated.

But please; let's coordinate directly -- we've done so frequently via Hangout during your GSOC in the past -- than devolving into unhelpful public shade-throwing at how maintenance is currently performed; that is, if the goal is to actually help the project.

-- Herbert

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

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 :

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

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-histor... [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 wrote:

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

-- 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-libraries+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAGtp2Sh8wRp7h-8P6N....

Am So., 12. Jan. 2020 um 09:32 Uhr schrieb 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.

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