One thing that would help a bit, I imagine, would be to improve the
treatment of unsafeDupablePerformIO in GHC so that bytestring can drop
the fragile accursedUnutterablePerformIO without significant
performance loss. There's been some discussion about how to do so, but
no resolution has been reached.
On Thu, Dec 19, 2019 at 11:21 AM Simon Jakobi via Libraries
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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries