Proposal: Expanding the CLC

[Oleg Grenrus]

Re: 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.

These are non-maintainer uploads and is a job of Hackage Trustees (for
all of Hackage, not only some "better" packages).
https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#3-source-changes-simple-patches

Anyone can prepare the patch.

- Oleg

On 12.2.2021 1.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/20210212/7ef3196f/attachment.html>