Proposal: Expanding the CLC

[Alexey Khudaykov]

I think that we should understand what exactly does CLC do? What should 
it do?

What is the problem at hand? Important packages in haskell ecosystem are not
properly maintained. Solution? They need maintainers. Should they be 
members of
CLC? I'm not sure. CLC membership is 3 years, maintainers usually maintain
package until they stop. Should someone stop maintaining package if he's no
longer member of CLC?

Furthermore I would argue that:

 > several maintainers who are not CLC members have been forced to step 
up to
 > help take on some of the maintenance burden for many of the CLC
 > libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more.

is step in the right direction. Committee in charge of maintaining 
package is
basically designed to just keep packages on life support without any 
significant
development. And it's exactly what happened. Package will be improved 
only when
maintainer cares about it. And it's not possible to care about all core 
libraries.

Should CLC maintain packages or find maintainers, resolve disputes etc? 
Does it
do software development or does it organize software development?

On 12.02.2021 02:54, Emily Pillmore wrote:
> Hi All,
>
> Over the past year, two things have become increasingly clear to me as 
> I've carried out my CLC duties:
>
>
> 1. The CLC is under-resourced. This is evidenced by the fact that 
> several maintainers who are not CLC members have been forced to step 
> up to help take on some of the maintenance burden for many of the CLC 
> libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. 
> The current CLC head count is not enough to dedicate at least one 
> maintainer per package, which is leading to us all being spread thin, 
> and the less-loved packages are falling into disrepair as a result. 
> Couple this with the fact that roughly half the CLC do not have these 
> packages actively within their maintenance cycles, and we arrive at 
> the current problem.
>
> 2. The current set of "core" libraries does not cover what is 
> generally considered "core" in the community. From now on, I'll refer 
> to "core" packages as "boot" packages, and identify core packages to 
> be those that are have proven to be incredibly popular tools for 
> building things in Haskell. For example `zlib`, `parsec`, 
> `regex-base`, `regex-posix`, `network`, etc. In particular, if any of 
> these core packages saw their current authors disappear, or 
> incapacitated in any sense, it would seriously harm the Haskell 
> ecosystem. `cabal-install`, for example, requires several of those 
> packages as upstream dependencies. Currently, we are dealing with this 
> nightmare situation where work is stalled across many packages due to 
> a particular set of maintainers being very difficult to reach, one of 
> whom having disappeared completely for all maintenance intents and 
> purposes.
>
> Ergo, we have a problem. Thankfully, many people have stepped up 
> showing renewed interest in maintaining such packages with the latest 
> crop of CLC folks, and this poses an interesting opportunity.
>
> My proposal is this:
>
> 1. We expand the CLC from 9 members to 22 members such that we have at 
> least 1 CLC maintainer per boot package. There are a large number of 
> fantastic candidates already available, who would be perfect for the 
> role. In fact, many of the candidates whom we would ask are already 
> maintaining these packages. In particular, Andrew Lelechenko, Simon 
> Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are 
> already serving within this role (and thank you for it!). Andreas Abel 
> has also offered to help take on one of the core packages.
>
> 2. We consider a dedicated "Haskell Action Team" (name and idea 
> courtesy of Carter Schonwald) to oversee packages in the Haskell 
> github repo that can act as supplementary maintainers for many of the 
> core packages contained therein. Currently, there are many in need of 
> help. `zlib` comes to mind, which is currently blocking 
> `bytestring-0.11` migration work due to having no available maintainer 
> with the permissions to do a release. This, in turn, is stalling 
> `cabal-install`. Short of taking over the package, we would have to 
> ask for an emergency Hackage release if the neither maintainer shows 
> up to do it in a reasonable time frame.
>
> This is just one step towards helping ease the burden of maintenance 
> of so-called core and boot packages. I hope you agree that this is a 
> good idea, and if we get enough thumbs up, then Chessai and I will 
> draw up the necessary changes to the CLC remit and we'll get started!
>
> Cheers,
> Emily
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210217/fbc978bf/attachment.html>