From david.feuer at gmail.com Fri Feb 5 21:22:27 2021 From: david.feuer at gmail.com (David Feuer) Date: Fri, 5 Feb 2021 16:22:27 -0500 Subject: Proposal: export more Data.Sequence internals Message-ID: I'd like containers to export more Data.Sequence internals, and to do so in a way that allows external users to rely on them. I propose the following: 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the finger trees used to represent sequences. These can also be used for other finger trees with measurements in the (Int, +) monoid. This would include various basic operations for cons, snoc, and splitting, with most names the same as for sequences. 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient mapping/traversing functions that rely on specific preconditions to maintain the internal fingertree annotation invariant. 3. Add a module, Data.Sequence.StableInternal, exporting the internal structure of sequences and also some internal functions that may be useful elsewhere (I'm particularly interested in the `splitMap` function and future variants thereof). Unlike the `.Internal` module, this module would be subject to the package version policy, and would therefore be more suitable for use by other packages. I am very open to suggestions for modifications to the module names. One option might be to put all the FingerTree.IntPlus stuff in the Data.Sequence.StableInternal hierarchy, if folks think it should be buried a bit. David From zemyla at gmail.com Sat Feb 6 00:07:05 2021 From: zemyla at gmail.com (Zemyla) Date: Fri, 5 Feb 2021 18:07:05 -0600 Subject: Proposal: export more Data.Sequence internals In-Reply-To: References: Message-ID: I was sort of thinking of something similar, but what I would want to export would be constructors for it: data Seq a = Empty | Single a | More {-# UNPACK #-} !(Seq2 a) where a Seq2 is basically the Deep constructor as a type, and represents a Seq with 2 or more values in it. Though I expect this won't happen until we start using dependent types to express the difference between possibly-empty and nonempty sequences. On Fri, Feb 5, 2021, 15:22 David Feuer wrote: > I'd like containers to export more Data.Sequence internals, and to do > so in a way that allows external users to rely on them. I propose the > following: > > 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the > finger trees used to represent sequences. These can also be used for > other finger trees with measurements in the (Int, +) monoid. This > would include various basic operations for cons, snoc, and splitting, > with most names the same as for sequences. > 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient > mapping/traversing functions that rely on specific preconditions to > maintain the internal fingertree annotation invariant. > 3. Add a module, Data.Sequence.StableInternal, exporting the internal > structure of sequences and also some internal functions that may be > useful elsewhere (I'm particularly interested in the `splitMap` > function and future variants thereof). Unlike the `.Internal` module, > this module would be subject to the package version policy, and would > therefore be more suitable for use by other packages. > > I am very open to suggestions for modifications to the module names. > One option might be to put all the FingerTree.IntPlus stuff in the > Data.Sequence.StableInternal hierarchy, if folks think it should be > buried a bit. > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Feb 6 00:13:16 2021 From: david.feuer at gmail.com (David Feuer) Date: Fri, 5 Feb 2021 19:13:16 -0500 Subject: Proposal: export more Data.Sequence internals In-Reply-To: References: Message-ID: That's not the current representation of sequences, and making that change would be a significant project I can't undertake at the moment. I'm not proposing to freeze the sequence representation solid; just to bring it under PVP and make it more accessible/usable to other packages. I also want the (Int,+) finger trees for a currently-toy project playing with incremental quicksort for sequences. On Fri, Feb 5, 2021, 7:07 PM Zemyla wrote: > I was sort of thinking of something similar, but what I would want to > export would be constructors for it: > > data Seq a > = Empty > | Single a > | More {-# UNPACK #-} !(Seq2 a) > > where a Seq2 is basically the Deep constructor as a type, and represents a > Seq with 2 or more values in it. Though I expect this won't happen until we > start using dependent types to express the difference between > possibly-empty and nonempty sequences. > > On Fri, Feb 5, 2021, 15:22 David Feuer wrote: > >> I'd like containers to export more Data.Sequence internals, and to do >> so in a way that allows external users to rely on them. I propose the >> following: >> >> 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the >> finger trees used to represent sequences. These can also be used for >> other finger trees with measurements in the (Int, +) monoid. This >> would include various basic operations for cons, snoc, and splitting, >> with most names the same as for sequences. >> 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient >> mapping/traversing functions that rely on specific preconditions to >> maintain the internal fingertree annotation invariant. >> 3. Add a module, Data.Sequence.StableInternal, exporting the internal >> structure of sequences and also some internal functions that may be >> useful elsewhere (I'm particularly interested in the `splitMap` >> function and future variants thereof). Unlike the `.Internal` module, >> this module would be subject to the package version policy, and would >> therefore be more suitable for use by other packages. >> >> I am very open to suggestions for modifications to the module names. >> One option might be to put all the FingerTree.IntPlus stuff in the >> Data.Sequence.StableInternal hierarchy, if folks think it should be >> buried a bit. >> >> David >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at wils.online Sun Feb 7 05:10:58 2021 From: george at wils.online (George Wilson) Date: Sun, 7 Feb 2021 15:10:58 +1000 Subject: Proposal: export more Data.Sequence internals In-Reply-To: References: Message-ID: Sounds reasonable to me. I don't have any particular input on the module names or hierarchy. Cheers, George On Sat, 6 Feb 2021, 07:22 David Feuer, wrote: > I'd like containers to export more Data.Sequence internals, and to do > so in a way that allows external users to rely on them. I propose the > following: > > 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the > finger trees used to represent sequences. These can also be used for > other finger trees with measurements in the (Int, +) monoid. This > would include various basic operations for cons, snoc, and splitting, > with most names the same as for sequences. > 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient > mapping/traversing functions that rely on specific preconditions to > maintain the internal fingertree annotation invariant. > 3. Add a module, Data.Sequence.StableInternal, exporting the internal > structure of sequences and also some internal functions that may be > useful elsewhere (I'm particularly interested in the `splitMap` > function and future variants thereof). Unlike the `.Internal` module, > this module would be subject to the package version policy, and would > therefore be more suitable for use by other packages. > > I am very open to suggestions for modifications to the module names. > One option might be to put all the FingerTree.IntPlus stuff in the > Data.Sequence.StableInternal hierarchy, if folks think it should be > buried a bit. > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Feb 7 14:41:45 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 7 Feb 2021 09:41:45 -0500 Subject: Proposal: export more Data.Sequence internals In-Reply-To: References: Message-ID: What are some down sides that exposing these could entail? Like, what are data structure changes in implementation that are worth exploring that suddenly become major version bumps whereas before they’d be invisible improvements Is there any way backpack and or cabals multi library package support can help here ? On Fri, Feb 5, 2021 at 4:22 PM David Feuer wrote: > I'd like containers to export more Data.Sequence internals, and to do > so in a way that allows external users to rely on them. I propose the > following: > > 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the > finger trees used to represent sequences. These can also be used for > other finger trees with measurements in the (Int, +) monoid. This > would include various basic operations for cons, snoc, and splitting, > with most names the same as for sequences. > 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient > mapping/traversing functions that rely on specific preconditions to > maintain the internal fingertree annotation invariant. > 3. Add a module, Data.Sequence.StableInternal, exporting the internal > structure of sequences and also some internal functions that may be > useful elsewhere (I'm particularly interested in the `splitMap` > function and future variants thereof). Unlike the `.Internal` module, > this module would be subject to the package version policy, and would > therefore be more suitable for use by other packages. > > I am very open to suggestions for modifications to the module names. > One option might be to put all the FingerTree.IntPlus stuff in the > Data.Sequence.StableInternal hierarchy, if folks think it should be > buried a bit. > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Sun Feb 7 22:26:12 2021 From: chessai1996 at gmail.com (chessai) Date: Sun, 7 Feb 2021 16:26:12 -0600 Subject: Unix package maintenance Message-ID: All, The unix package, a core library, has been stalling. (just some examples, going back up to 6 years: [1] [2] [3] [4]). Previously, unix was maintained by HVR, a prolific maintainer and open source contributor of the Haskell ecosystem. His work to date has been invaluable for many of us today. However, recently, he's been increasingly unavailable, which happens and is perfectly understandable - life happens. But, the ecosystem cannot stall (eg [5], [6]) because of a single contributor, regardless of that contributor's merits or previous work. Right now, we have many useful (and in some cases necessary for other work, e.g, for hackage-server 2.0) patches to unix which need to be acted on. Additionally, there are potential maintainers willing to do the work ([7], [8], [9], [10]). On behalf of the CLC, which owns unix, I am announcing that the unix library will henceforth be under maintainership of the aforementioned individuals, who are all trusted and knowledgeable members of the community, looking to improve the library. I appreciate everyone who has contributed code to unix, maintained unix in the past, and those who stepped forward to help maintain it going forward. I hope that these changes will help facilitate positive growth for the library and ultimately the community, as they have with other core libraries which have recently been given new supplies of maintainers. [1]: https://github.com/haskell/unix/pull/145 [2]: https://github.com/haskell/unix/pull/21 [3]: https://github.com/haskell/unix/pull/110 [4]: https://github.com/haskell/unix/pull/122 [5]: https://github.com/haskell/zlib/pull/37 [6]: https://github.com/haskell/zlib/pull/39#issuecomment-774598088 [7]: https://github.com/hs-viktor [8]: https://github.com/Bodigrim [9]: https://github.com/emilypi [10]: https://github.com/davean -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Sun Feb 7 22:50:44 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Sun, 07 Feb 2021 22:50:44 +0000 Subject: Unix package maintenance In-Reply-To: References: Message-ID: Thanks Chessai. I'd like to just reaffirm to everyone that HVR is welcome to continue maintaining  when he becomes available again, and that this is to make sure that we take on some of the burden of packages thrust onto him over the past decade. We want to unblock everyone else's efforts so we don't end up depending entirely on any one maintainer at any time for trivial things like keeping deps up to date. Cheers, Emily On Sun, Feb 07, 2021 at 5:26 PM, chessai < chessai1996 at gmail.com > wrote: > > All, > > > The unix package, a core library, has been stalling. (just some examples, > going back up to 6 years: [1] [2] [3] [4]). > > > Previously, unix was maintained by HVR, a prolific maintainer and open > source contributor of the Haskell ecosystem. His work to date has been > invaluable for many of us today. However, recently, he's been increasingly > unavailable, which happens and is perfectly understandable - life happens. > But, the ecosystem cannot stall (eg [5], [6]) because of a single > contributor, regardless of that contributor's merits or previous work. > > > Right now, we have many useful (and in some cases necessary for other > work, e.g, for hackage-server 2.0) patches to unix which need to be acted > on. Additionally, there are potential maintainers willing to do the work > ([7], [8], [9], [10]). > > > On behalf of the CLC, which owns unix, I am announcing that the unix > library will henceforth be under maintainership of the aforementioned > individuals, who are all trusted and knowledgeable members of the > community, looking to improve the library. > > > I appreciate everyone who has contributed code to unix, maintained unix in > the past, and those who stepped forward to help maintain it going forward. > I hope that these changes will help facilitate positive growth for the > library and ultimately the community, as they have with other core > libraries which have recently been given new supplies of maintainers. > > > [1]: https:/ / github. com/ haskell/ unix/ pull/ 145 ( > https://github.com/haskell/unix/pull/145 ) > [2]: https:/ / github. com/ haskell/ unix/ pull/ 21 ( > https://github.com/haskell/unix/pull/21 ) > [3]: https:/ / github. com/ haskell/ unix/ pull/ 110 ( > https://github.com/haskell/unix/pull/110 ) > [4]: https:/ / github. com/ haskell/ unix/ pull/ 122 ( > https://github.com/haskell/unix/pull/122 ) > [5]: https:/ / github. com/ haskell/ zlib/ pull/ 37 ( > https://github.com/haskell/zlib/pull/37 ) > [6]: https:/ / github. com/ haskell/ zlib/ pull/ 39#issuecomment-774598088 > ( https://github.com/haskell/zlib/pull/39#issuecomment-774598088 ) > [7]: https:/ / github. com/ hs-viktor ( https://github.com/hs-viktor ) > [8]: https:/ / github. com/ Bodigrim ( https://github.com/Bodigrim ) > [9]: https:/ / github. com/ emilypi ( https://github.com/emilypi ) > [10]: https:/ / github. com/ davean ( https://github.com/davean ) > > > _______________________________________________ > Libraries mailing list > Libraries@ haskell. org ( Libraries at haskell.org ) > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Thu Feb 11 23:54:19 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Thu, 11 Feb 2021 23:54:19 +0000 Subject: Proposal: Expanding the CLC Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 12 00:13:14 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 11 Feb 2021 19:13:14 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: References: Message-ID: These are good points I think this is actually 3-5 points: CLC related 1) clc authority is strictly about leadership for helping make design decisions for base the package 2) clc is meant to be a fallback to ensure that there’s backup continuity for maintainership of ghc boot libraries and a design aid for Haskell library authors who are the current maintainers. But as long as the current maintainership is reachable for communication, the maintainer has final authority. — the clc violated this in spring 2020, while there were car burnings in the neighborhood of the maintainer in question . Bad taste. 3) peripherically clc via base maintainership is the design authority for the library section of the Haskell standard. —- point being: if you’re not contributing to design decisions for base. you shouldn’t be on the clc. If you are, then you should perhaps be on clc. The current makeup of the clc does not reflect that. — further more , growing clc should be a reflection of contributors being recognized for their design/hackery contribs HAT related 4) the idea/goal of hat: empowering and supporting active contributors while not saddling them with official commitments. Rather, HAT is about somone (myself initially), acting as a shield to support current active contributors to enable them to act with greater confidence. I like to think I helped enable that with some of the folks emily mentioned, especially Simon jakobi, viktor and Andrew L. On Thu, Feb 11, 2021 at 6:54 PM 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: From carter.schonwald at gmail.com Fri Feb 12 00:32:13 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 11 Feb 2021 19:32:13 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: References: Message-ID: I guess my main point is that this mailing list reflects and via predating clc, defines what clc is for. And rather than scope creep a single responsibility, articulating that need and facilitating is as a distinct entity is valuable. My idea with HAT is like a modern volunteer organizing touch point of Ye olde Haskell janitors, with each year some different set of folks who were active the previous year as new leadership/organizing touch points for helping facilitate active contributors the subsequent year. Designing for churn to stay fresh as a different take than how we’ve done many of these entity’s for Haskell. Actual Maintainer-ship responsibility should not be via Hat (at least as I envision it), though supporting and empowering active contributors may happily result in some of them being contrib i/ comaintainer. Equally important: library maintainers being responsive about bug fixes is important. Just as important is allowing them agency to evolve the Libs they maintain. I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue. On Thu, Feb 11, 2021 at 7:13 PM Carter Schonwald wrote: > These are good points > > I think this is actually 3-5 points: > > > CLC related > 1) clc authority is strictly about leadership for helping make design > decisions for base the package > > 2) clc is meant to be a fallback to ensure that there’s backup continuity > for maintainership of ghc boot libraries and a design aid for Haskell > library authors who are the current maintainers. > > But as long as the current maintainership is reachable for communication, > the maintainer has final authority. > — the clc violated this in spring 2020, while there were car burnings in > the neighborhood of the maintainer in question . Bad taste. > > 3) peripherically clc via base maintainership is the design authority for > the library section of the Haskell standard. > > —- point being: if you’re not contributing to design decisions for base. > you shouldn’t be on the clc. If you are, then you should perhaps be on > clc. The current makeup of the clc does not reflect that. > > — further more , growing clc should be a reflection of contributors being > recognized for their design/hackery contribs > > HAT related > 4) the idea/goal of hat: empowering and supporting active contributors > while not saddling them with official commitments. Rather, HAT is about > somone (myself initially), acting as a shield to support current active > contributors to enable them to act with greater confidence. I like to think > I helped enable that with some of the folks emily mentioned, especially > Simon jakobi, viktor and Andrew L. > > On Thu, Feb 11, 2021 at 6:54 PM 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: From hasufell at posteo.de Fri Feb 12 06:46:12 2021 From: hasufell at posteo.de (Julian Ospald) Date: Fri, 12 Feb 2021 06:46:12 +0000 Subject: Proposal: Expanding the CLC In-Reply-To: References: Message-ID: Hi, my opinion is that we should develop a zero tolerance towards unresponsive maintainership. Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer. The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must). I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time. Cheers, Julian On February 11, 2021 11:54:19 PM UTC, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Fri Feb 12 10:15:12 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 12 Feb 2021 12:15:12 +0200 Subject: Proposal: Expanding the CLC In-Reply-To: References: Message-ID: <3f604618-2318-950c-f4f0-148724d87206@iki.fi> 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: From john.ericson at obsidian.systems Sat Feb 13 20:03:04 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Sat, 13 Feb 2021 15:03:04 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: References: Message-ID: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them. I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible. John On 2/12/21 1:46 AM, Julian Ospald wrote: > Hi, > > my opinion is that we should develop a zero tolerance towards > unresponsive maintainership. > > Contributors shouldn't have to escalate on the ML and shouldn't have > to request package takeovers. These things are awkward and require > more dedication than necessary to be a valuable co-maintainer. > > The CLC should proactively scan for popular packages that require new > maintainer juice, contact the current maintainers and call for help on > the ML (whether core/boot/something-else doesn't really matter to > me... redefine the CLC competencies if you must). > > I've had many PRs over the years that took 6-12 months for a response. > This is not an acceptable response time. > > Cheers, > Julian > > On February 11, 2021 11:54:19 PM UTC, 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: From hasufell at posteo.de Sat Feb 13 21:24:04 2021 From: hasufell at posteo.de (Julian Ospald) Date: Sat, 13 Feb 2021 21:24:04 +0000 Subject: Proposal: Expanding the CLC In-Reply-To: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> Message-ID: Absolutely. I think there could very well be a platform that focuses solely on authorship. This could be made easier by enforcing package names to contain the authors username and then relying on package-qualified imports or something. Just random thoughts. But yeah, hackage is not that. It already contains various means to deal with maintainership that exceeds authorship. There's a good counter-argument to my proposal though, namely that it may undermine a users trust in a package, which may be based on the authors quality standards and their attitude. I agree it is an argument, but I also believe a body like the CLC has sufficient competency to make up for this. And it's also a reminder to every maintainer: make sure you have co-maintainers you trust, such that this will never become a problem. On February 13, 2021 8:03:04 PM UTC, John Ericson wrote: >Yeah I strongly agree with the sentiments here, and the concrete >measures. Thank you, Emily, for proposing them. > >I assume some people will be worried about undermining the prerogative >of individual maintainers. My view is this *not* a good reason to "hold > >the CLC back". A bit off topic, but In the long term, I am optimistic >for technical solutions to make dealing with libraries and versions, >alternative ecosystems, etc. easier. Basically I want it all---both >collaborative ownership and authorship, and healthy decentralized >experimentation---and I think that's possible. > >John > >On 2/12/21 1:46 AM, Julian Ospald wrote: >> Hi, >> >> my opinion is that we should develop a zero tolerance towards >> unresponsive maintainership. >> >> Contributors shouldn't have to escalate on the ML and shouldn't have >> to request package takeovers. These things are awkward and require >> more dedication than necessary to be a valuable co-maintainer. >> >> The CLC should proactively scan for popular packages that require new > >> maintainer juice, contact the current maintainers and call for help >on >> the ML (whether core/boot/something-else doesn't really matter to >> me... redefine the CLC competencies if you must). >> >> I've had many PRs over the years that took 6-12 months for a >response. >> This is not an acceptable response time. >> >> Cheers, >> Julian >> >> On February 11, 2021 11:54:19 PM UTC, 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: From carter.schonwald at gmail.com Sun Feb 14 00:01:52 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 13 Feb 2021 19:01:52 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> Message-ID: I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that. I’m more than happy to be wrong though On Sat, Feb 13, 2021 at 3:03 PM John Ericson wrote: > Yeah I strongly agree with the sentiments here, and the concrete measures. > Thank you, Emily, for proposing them. > > I assume some people will be worried about undermining the prerogative of > individual maintainers. My view is this *not* a good reason to "hold the > CLC back". A bit off topic, but In the long term, I am optimistic for > technical solutions to make dealing with libraries and versions, > alternative ecosystems, etc. easier. Basically I want it all---both > collaborative ownership and authorship, and healthy decentralized > experimentation---and I think that's possible. > > John > On 2/12/21 1:46 AM, Julian Ospald wrote: > > Hi, > > my opinion is that we should develop a zero tolerance towards unresponsive > maintainership. > > Contributors shouldn't have to escalate on the ML and shouldn't have to > request package takeovers. These things are awkward and require more > dedication than necessary to be a valuable co-maintainer. > > The CLC should proactively scan for popular packages that require new > maintainer juice, contact the current maintainers and call for help on the > ML (whether core/boot/something-else doesn't really matter to me... > redefine the CLC competencies if you must). > > I've had many PRs over the years that took 6-12 months for a response. > This is not an acceptable response time. > > Cheers, > Julian > > On February 11, 2021 11:54:19 PM UTC, 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 listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun Feb 14 20:19:55 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 14 Feb 2021 18:19:55 -0200 Subject: Maintenance of text-icu (Bryan O'Sullivan) In-Reply-To: <6f07330f-268a-dc80-8f39-5a1921ae2798@ifi.lmu.de> References: <3bb5fa8c-478e-e404-7ffb-a0a2a7de0e5f@ifi.lmu.de> <6f07330f-268a-dc80-8f39-5a1921ae2798@ifi.lmu.de> Message-ID: I am not sure about the current status of text-icu? What remains to be done to get it revived? > On Jan 11, 2021, at 8:56 AM, Andreas Abel wrote: > > Thanks Simon, for the update! (I hope it is nothing bad.) > > @Ben: Could you set us up? > (And would that include write permissions on bos/text-icu or a new repo?) > > On 2021-01-11 10:39, Simon Peyton Jones wrote: >> Bryan helpfully transferred ownership of >> * attoparsec >> * criterion >> * statistics >> * double-conversion >> * math-functions >> * aeson >> * text-icu >> * mwc-random >> * wreq >> * critbit >> * text-format >> Haskell.org (as a holding mechanism) on 8 Dec. This was a holding mechanism while we figure out who the new maintainers should be. Ben Gamari knows about this -- ask him. But I think Bryan is now out of the critical path. >> Simon -- Viktor. From john.ericson at obsidian.systems Mon Feb 15 18:07:36 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Mon, 15 Feb 2021 13:07:36 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> Message-ID: <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> Carter, It's not exactly clear to me where your two proposals differ? It seems like Emily said "bigger CLC" with HAT, while you are saying a separate org, perhaps with the CLC inside the HAT? I'm guessing the idea there is to make the degree of control inversely vary with the number of libraries in the purview? > I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue. Yes I would like to get into that at some point too. (Pithily put, my view is chop up each library until its contents are uncontroversial.) This is what makes me less concerned about the difference between a bigger CLC and rings of orgs. John On 2/13/21 7:01 PM, Carter Schonwald wrote: > I agree with your articulated long term goal points, I just worry that > we’re not investing in the right structures of organization to support > that.  I’m more than happy to be wrong though > > On Sat, Feb 13, 2021 at 3:03 PM John Ericson > wrote: > > Yeah I strongly agree with the sentiments here, and the concrete > measures. Thank you, Emily, for proposing them. > > I assume some people will be worried about undermining the > prerogative of individual maintainers. My view is this *not* a > good reason to "hold the CLC back". A bit off topic, but In the > long term, I am optimistic for technical solutions to make dealing > with libraries and versions, alternative ecosystems, etc. easier. > Basically I want it all---both collaborative ownership and > authorship, and healthy decentralized experimentation---and I > think that's possible. > > John > > On 2/12/21 1:46 AM, Julian Ospald wrote: >> Hi, >> >> my opinion is that we should develop a zero tolerance towards >> unresponsive maintainership. >> >> Contributors shouldn't have to escalate on the ML and shouldn't >> have to request package takeovers. These things are awkward and >> require more dedication than necessary to be a valuable >> co-maintainer. >> >> The CLC should proactively scan for popular packages that require >> new maintainer juice, contact the current maintainers and call >> for help on the ML (whether core/boot/something-else doesn't >> really matter to me... redefine the CLC competencies if you must). >> >> I've had many PRs over the years that took 6-12 months for a >> response. This is not an acceptable response time. >> >> Cheers, >> Julian >> >> On February 11, 2021 11:54:19 PM UTC, 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 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at wils.online Tue Feb 16 09:03:33 2021 From: george at wils.online (George Wilson) Date: Tue, 16 Feb 2021 19:03:33 +1000 Subject: Proposal: Expanding the CLC In-Reply-To: <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> Message-ID: I would be happy for the CLC to expand, assuming that qualified candidates step forward. Twenty-two seems rather optimistic to me, since we typically don't see many applicants. Perhaps it can be an aspirational goal. Regarding a "Haskell Action Team", I definitely think more maintainers on some core libraries and more active members of the Haskell github organisation would help, but I'm not sure we really need another named volunteer organisation established within Haskell. Between the CLC, the Hackage trustees, the Haskell.org Committee, the GHC Steering Committee, the Haskell Prime Committee (if it gets going again), and now the Foundation, we really do have a lot of those already. I bet I have even forgotten at least one! To attempt to form this new group, on top of expanding the CLC to twenty-two, would surely involve a significant overlap between the groups. Otherwise you'd have to conjure a lot more trusted, highly-advanced Haskellers with free time than I think exist. Cheers, George On Tue, 16 Feb 2021 at 04:11, John Ericson wrote: > Carter, > > It's not exactly clear to me where your two proposals differ? It seems > like Emily said "bigger CLC" with HAT, while you are saying a separate org, > perhaps with the CLC inside the HAT? I'm guessing the idea there is to make > the degree of control inversely vary with the number of libraries in the > purview? > > > I do worry that some Libs that fall under clc atm / as of the spring are > likely to never have serious evolution / improvement. But that’s a > different issue. > > Yes I would like to get into that at some point too. (Pithily put, my view > is chop up each library until its contents are uncontroversial.) This is > what makes me less concerned about the difference between a bigger CLC and > rings of orgs. > > John > On 2/13/21 7:01 PM, Carter Schonwald wrote: > > I agree with your articulated long term goal points, I just worry that > we’re not investing in the right structures of organization to support > that. I’m more than happy to be wrong though > > On Sat, Feb 13, 2021 at 3:03 PM John Ericson > wrote: > >> Yeah I strongly agree with the sentiments here, and the concrete >> measures. Thank you, Emily, for proposing them. >> >> I assume some people will be worried about undermining the prerogative of >> individual maintainers. My view is this *not* a good reason to "hold the >> CLC back". A bit off topic, but In the long term, I am optimistic for >> technical solutions to make dealing with libraries and versions, >> alternative ecosystems, etc. easier. Basically I want it all---both >> collaborative ownership and authorship, and healthy decentralized >> experimentation---and I think that's possible. >> >> John >> On 2/12/21 1:46 AM, Julian Ospald wrote: >> >> Hi, >> >> my opinion is that we should develop a zero tolerance towards >> unresponsive maintainership. >> >> Contributors shouldn't have to escalate on the ML and shouldn't have to >> request package takeovers. These things are awkward and require more >> dedication than necessary to be a valuable co-maintainer. >> >> The CLC should proactively scan for popular packages that require new >> maintainer juice, contact the current maintainers and call for help on the >> ML (whether core/boot/something-else doesn't really matter to me... >> redefine the CLC competencies if you must). >> >> I've had many PRs over the years that took 6-12 months for a response. >> This is not an acceptable response time. >> >> Cheers, >> Julian >> >> On February 11, 2021 11:54:19 PM UTC, 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 listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Feb 16 13:56:55 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 16 Feb 2021 08:56:55 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> Message-ID: There’s a lot more smart quiet folks who just need the right cheerleading and guidance out there than you’d expect. Or any of us can imagine. The way anyone gets great at stuff starts from somewhere, and we need to seriously consider and work at making sure the ramp/funnel of participation and inclusion is as wide as possible. Current Haskell processes are not really setup to handle continuity and growth of participation as well as we should aim for. The entire premise/ point of new efforts like the Haskell foundation is that we need to genuinely ask: how do we help more folks get great at their software needs, and facilitate Haskell and or ideas embodied thereof, empowering more folks over time. And this attitude should be reflected in how we evolve and improve and maintain core infra tools and libraries. On Tue, Feb 16, 2021 at 4:04 AM George Wilson wrote: > I would be happy for the CLC to expand, assuming that qualified candidates > step forward. > Twenty-two seems rather optimistic to me, since we typically don't see > many applicants. Perhaps it can be an aspirational goal. > > Regarding a "Haskell Action Team", I definitely think more maintainers on > some core libraries and more active members of the Haskell github > organisation would help, but I'm not sure we really need another named > volunteer organisation established within Haskell. Between the CLC, the > Hackage trustees, the Haskell.org Committee, the GHC Steering Committee, > the Haskell Prime Committee (if it gets going again), and now the > Foundation, we really do have a lot of those already. I bet I have even > forgotten at least one! > To attempt to form this new group, on top of expanding the CLC to > twenty-two, would surely involve a significant overlap between the groups. > Otherwise you'd have to conjure a lot more trusted, highly-advanced > Haskellers with free time than I think exist. > > Cheers, > George > > On Tue, 16 Feb 2021 at 04:11, John Ericson > wrote: > >> Carter, >> >> It's not exactly clear to me where your two proposals differ? It seems >> like Emily said "bigger CLC" with HAT, while you are saying a separate org, >> perhaps with the CLC inside the HAT? I'm guessing the idea there is to make >> the degree of control inversely vary with the number of libraries in the >> purview? >> >> > I do worry that some Libs that fall under clc atm / as of the spring >> are likely to never have serious evolution / improvement. But that’s a >> different issue. >> >> Yes I would like to get into that at some point too. (Pithily put, my >> view is chop up each library until its contents are uncontroversial.) This >> is what makes me less concerned about the difference between a bigger CLC >> and rings of orgs. >> >> John >> On 2/13/21 7:01 PM, Carter Schonwald wrote: >> >> I agree with your articulated long term goal points, I just worry that >> we’re not investing in the right structures of organization to support >> that. I’m more than happy to be wrong though >> >> On Sat, Feb 13, 2021 at 3:03 PM John Ericson >> wrote: >> >>> Yeah I strongly agree with the sentiments here, and the concrete >>> measures. Thank you, Emily, for proposing them. >>> >>> I assume some people will be worried about undermining the prerogative >>> of individual maintainers. My view is this *not* a good reason to "hold the >>> CLC back". A bit off topic, but In the long term, I am optimistic for >>> technical solutions to make dealing with libraries and versions, >>> alternative ecosystems, etc. easier. Basically I want it all---both >>> collaborative ownership and authorship, and healthy decentralized >>> experimentation---and I think that's possible. >>> >>> John >>> On 2/12/21 1:46 AM, Julian Ospald wrote: >>> >>> Hi, >>> >>> my opinion is that we should develop a zero tolerance towards >>> unresponsive maintainership. >>> >>> Contributors shouldn't have to escalate on the ML and shouldn't have to >>> request package takeovers. These things are awkward and require more >>> dedication than necessary to be a valuable co-maintainer. >>> >>> The CLC should proactively scan for popular packages that require new >>> maintainer juice, contact the current maintainers and call for help on the >>> ML (whether core/boot/something-else doesn't really matter to me... >>> redefine the CLC competencies if you must). >>> >>> I've had many PRs over the years that took 6-12 months for a response. >>> This is not an acceptable response time. >>> >>> Cheers, >>> Julian >>> >>> On February 11, 2021 11:54:19 PM UTC, 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 listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Feb 16 15:26:56 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 16 Feb 2021 17:26:56 +0200 Subject: Takeover of hashable and uuid & uuid-types packages Message-ID: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> I ask to take over the maintenance of hashable, uuid and uuid-types packages. I'm a maintainer of packages depending on them (most notably quickcheck-instances and aeson). I should also mention that when we (Herbert and I) took over Antoine Latter's packages, I took over quickcheck-instances and Herbert took over uuid and parsec. We should taken over together in the first place. My first points of action would be: - make a releases supporting latest versions of dependencies (GHC-9.0, bytestring-0.11) and - move packages to https://github.com/haskellari organization, so in case of my absence there are people (Ryan Scott, bodigrim, few others) who will be able to act. Best regards, Oleg From oleg.grenrus at iki.fi Tue Feb 16 16:27:05 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 16 Feb 2021 18:27:05 +0200 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> Message-ID: <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> github.com/haskell is fine too. I have uneasy feeling about its current "chaotic good" management model though, but I can live with it. OTOH, you can simply bother me about any package in haskellari org. Clear and simple. - Oleg On 16.2.2021 17.56, Johan Tibell wrote: > I'm not involved anymore so it's fine by me but why > not https://github.com/haskell? > > On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus > wrote: > > I ask to take over the maintenance of hashable, uuid and uuid-types > packages. > > I'm a maintainer of packages depending on them (most notably > quickcheck-instances and aeson). > > I should also mention that when we (Herbert and I) took over Antoine > Latter's packages, I took over quickcheck-instances and Herbert took > over uuid and parsec. We should taken over together in the first > place. > > My first points of action would be: > - make a releases supporting latest versions of dependencies (GHC-9.0, > bytestring-0.11) and > - move packages to https://github.com/haskellari organization, so in > case of my absence there are people (Ryan Scott, bodigrim, few others) > who will be able to act. > > Best regards, > Oleg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Feb 16 16:37:53 2021 From: david.feuer at gmail.com (David Feuer) Date: Tue, 16 Feb 2021 11:37:53 -0500 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: My general view is that it's best for each package (or closely allied family of packages) to have its own GitHub organization. On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus wrote: > github.com/haskell is fine too. I have uneasy feeling about its current > "chaotic good" management model though, but I can live with it. > > OTOH, you can simply bother me about any package in haskellari org. Clear > and simple. > > - Oleg > On 16.2.2021 17.56, Johan Tibell wrote: > > I'm not involved anymore so it's fine by me but why not > https://github.com/haskell? > > On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus wrote: > >> I ask to take over the maintenance of hashable, uuid and uuid-types >> packages. >> >> I'm a maintainer of packages depending on them (most notably >> quickcheck-instances and aeson). >> >> I should also mention that when we (Herbert and I) took over Antoine >> Latter's packages, I took over quickcheck-instances and Herbert took >> over uuid and parsec. We should taken over together in the first place. >> >> My first points of action would be: >> - make a releases supporting latest versions of dependencies (GHC-9.0, >> bytestring-0.11) and >> - move packages to https://github.com/haskellari organization, so in >> case of my absence there are people (Ryan Scott, bodigrim, few others) >> who will be able to act. >> >> Best regards, >> Oleg >> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Feb 16 16:41:48 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 16 Feb 2021 18:41:48 +0200 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: I don't disagree. Having hashable live next to unordered-containers in https://github.com/haskell-unordered-containers would be fine too, if you, David, agree with that. - Oleg On 16.2.2021 18.37, David Feuer wrote: > My general view is that it's best for each package (or closely allied > family of packages) to have its own GitHub organization. > > On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus > wrote: > > github.com/haskell is fine too. I have > uneasy feeling about its current "chaotic good" management model > though, but I can live with it. > > OTOH, you can simply bother me about any package in haskellari > org. Clear and simple. > > - Oleg > > On 16.2.2021 17.56, Johan Tibell wrote: >> I'm not involved anymore so it's fine by me but why >> not https://github.com/haskell? >> >> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus > > wrote: >> >> I ask to take over the maintenance of hashable, uuid and >> uuid-types >> packages. >> >> I'm a maintainer of packages depending on them (most notably >> quickcheck-instances and aeson). >> >> I should also mention that when we (Herbert and I) took over >> Antoine >> Latter's packages, I took over quickcheck-instances and >> Herbert took >> over uuid and parsec. We should taken over together in the >> first place. >> >> My first points of action would be: >> - make a releases supporting latest versions of dependencies >> (GHC-9.0, >> bytestring-0.11) and >> - move packages to https://github.com/haskellari >> organization, so in >> case of my absence there are people (Ryan Scott, bodigrim, >> few others) >> who will be able to act. >> >> Best regards, >> Oleg >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Feb 16 16:43:44 2021 From: david.feuer at gmail.com (David Feuer) Date: Tue, 16 Feb 2021 11:43:44 -0500 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: That would be fine. On Tue, Feb 16, 2021, 11:41 AM Oleg Grenrus wrote: > I don't disagree. Having hashable live next to unordered-containers in > https://github.com/haskell-unordered-containers would be fine too, if > you, David, agree with that. > > - Oleg > On 16.2.2021 18.37, David Feuer wrote: > > My general view is that it's best for each package (or closely allied > family of packages) to have its own GitHub organization. > > On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus wrote: > >> github.com/haskell is fine too. I have uneasy feeling about its current >> "chaotic good" management model though, but I can live with it. >> >> OTOH, you can simply bother me about any package in haskellari org. Clear >> and simple. >> >> - Oleg >> On 16.2.2021 17.56, Johan Tibell wrote: >> >> I'm not involved anymore so it's fine by me but why not >> https://github.com/haskell? >> >> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus wrote: >> >>> I ask to take over the maintenance of hashable, uuid and uuid-types >>> packages. >>> >>> I'm a maintainer of packages depending on them (most notably >>> quickcheck-instances and aeson). >>> >>> I should also mention that when we (Herbert and I) took over Antoine >>> Latter's packages, I took over quickcheck-instances and Herbert took >>> over uuid and parsec. We should taken over together in the first place. >>> >>> My first points of action would be: >>> - make a releases supporting latest versions of dependencies (GHC-9.0, >>> bytestring-0.11) and >>> - move packages to https://github.com/haskellari organization, so in >>> case of my absence there are people (Ryan Scott, bodigrim, few others) >>> who will be able to act. >>> >>> Best regards, >>> Oleg >>> >>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Tue Feb 16 16:50:24 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Tue, 16 Feb 2021 16:50:24 +0000 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: Thanks for taking this on Oleg On Tue, Feb 16, 2021 at 11:43 AM, David Feuer < david.feuer at gmail.com > wrote: > > That would be fine. > > On Tue, Feb 16, 2021, 11:41 AM Oleg Grenrus < oleg. grenrus@ iki. fi ( > oleg.grenrus at iki.fi ) > wrote: > > >> >> >> I don't disagree. Having hashable live next to unordered-containers in https:/ >> / github. com/ haskell-unordered-containers ( >> https://github.com/haskell-unordered-containers ) would be fine too, if >> you, David, agree with that. >> >> - Oleg >> >> >> On 16.2.2021 18.37, David Feuer wrote: >> >> >>> My general view is that it's best for each package (or closely allied >>> family of packages) to have its own GitHub organization. >>> >>> On Tue, Feb 16 , 2021, 11:27 AM Oleg Grenrus < oleg. grenrus@ iki. fi ( >>> oleg.grenrus at iki.fi ) > wrote: >>> >>> >>>> >>>> >>>> github. com/ haskell ( http://github.com/haskell ) is fine too. I have >>>> uneasy feeling about its current "chaotic good" management model though, >>>> but I can live with it. >>>> >>>> OTOH, you can simply bother me about any package in haskellari org. Clear >>>> and simple. >>>> >>>> - Oleg >>>> >>>> >>>> On 16.2.2021 17.56, Johan Tibell wrote: >>>> >>>> >>>>> I'm not involved anymore so it's fine by me but why not https:/ / github. com/ >>>>> haskell ( https://github.com/haskell ) ? >>>>> >>>>> On Tue, Feb 16 , 2021 at 4:26 PM Oleg Grenrus < oleg. grenrus@ iki. fi ( >>>>> oleg.grenrus at iki.fi ) > wrote: >>>>> >>>>> >>>>>> I ask to take over the maintenance of hashable, uuid and uuid-types >>>>>> packages. >>>>>> >>>>>> I'm a maintainer of packages depending on them (most notably >>>>>> quickcheck-instances and aeson). >>>>>> >>>>>> I should also mention that when we (Herbert and I) took over Antoine >>>>>> Latter's packages, I took over quickcheck-instances and Herbert took >>>>>> over uuid and parsec. We should taken over together in the first place. >>>>>> >>>>>> My first points of action would be: >>>>>> - make a releases supporting latest versions of dependencies (GHC-9.0, >>>>>> bytestring-0.11) and >>>>>> - move packages to https:/ / github. com/ haskellari ( >>>>>> https://github.com/haskellari ) organization, so in >>>>>> case of my absence there are people (Ryan Scott, bodigrim, few others) >>>>>> who will be able to act. >>>>>> >>>>>> Best regards, >>>>>> Oleg >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>> >>> >>> >>> >> >> > > > > _______________________________________________ > Libraries mailing list > Libraries@ haskell. org ( Libraries at haskell.org ) > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Tue Feb 16 16:53:35 2021 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Tue, 16 Feb 2021 17:53:35 +0100 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: Sounds reasonable to me! Am Di., 16. Feb. 2021 um 17:42 Uhr schrieb Oleg Grenrus : > I don't disagree. Having hashable live next to unordered-containers in > https://github.com/haskell-unordered-containers would be fine too, if > you, David, agree with that. > > - Oleg > On 16.2.2021 18.37, David Feuer wrote: > > My general view is that it's best for each package (or closely allied > family of packages) to have its own GitHub organization. > > On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus wrote: > >> github.com/haskell is fine too. I have uneasy feeling about its current >> "chaotic good" management model though, but I can live with it. >> >> OTOH, you can simply bother me about any package in haskellari org. Clear >> and simple. >> >> - Oleg >> On 16.2.2021 17.56, Johan Tibell wrote: >> >> I'm not involved anymore so it's fine by me but why not >> https://github.com/haskell? >> >> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus wrote: >> >>> I ask to take over the maintenance of hashable, uuid and uuid-types >>> packages. >>> >>> I'm a maintainer of packages depending on them (most notably >>> quickcheck-instances and aeson). >>> >>> I should also mention that when we (Herbert and I) took over Antoine >>> Latter's packages, I took over quickcheck-instances and Herbert took >>> over uuid and parsec. We should taken over together in the first place. >>> >>> My first points of action would be: >>> - make a releases supporting latest versions of dependencies (GHC-9.0, >>> bytestring-0.11) and >>> - move packages to https://github.com/haskellari organization, so in >>> case of my absence there are people (Ryan Scott, bodigrim, few others) >>> who will be able to act. >>> >>> Best regards, >>> Oleg >>> >>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Feb 16 17:28:01 2021 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 16 Feb 2021 09:28:01 -0800 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: As someone currently being bitten by the status quo, this sounds eminently practical. Either version of you just claiming it, or placing control of it with unordered-containers works fine. -Edward On Tue, Feb 16, 2021 at 8:54 AM Simon Jakobi via Libraries < libraries at haskell.org> wrote: > Sounds reasonable to me! > > Am Di., 16. Feb. 2021 um 17:42 Uhr schrieb Oleg Grenrus < > oleg.grenrus at iki.fi>: > >> I don't disagree. Having hashable live next to unordered-containers in >> https://github.com/haskell-unordered-containers would be fine too, if >> you, David, agree with that. >> >> - Oleg >> On 16.2.2021 18.37, David Feuer wrote: >> >> My general view is that it's best for each package (or closely allied >> family of packages) to have its own GitHub organization. >> >> On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus wrote: >> >>> github.com/haskell is fine too. I have uneasy feeling about its current >>> "chaotic good" management model though, but I can live with it. >>> >>> OTOH, you can simply bother me about any package in haskellari org. >>> Clear and simple. >>> >>> - Oleg >>> On 16.2.2021 17.56, Johan Tibell wrote: >>> >>> I'm not involved anymore so it's fine by me but why not >>> https://github.com/haskell? >>> >>> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus >>> wrote: >>> >>>> I ask to take over the maintenance of hashable, uuid and uuid-types >>>> packages. >>>> >>>> I'm a maintainer of packages depending on them (most notably >>>> quickcheck-instances and aeson). >>>> >>>> I should also mention that when we (Herbert and I) took over Antoine >>>> Latter's packages, I took over quickcheck-instances and Herbert took >>>> over uuid and parsec. We should taken over together in the first place. >>>> >>>> My first points of action would be: >>>> - make a releases supporting latest versions of dependencies (GHC-9.0, >>>> bytestring-0.11) and >>>> - move packages to https://github.com/haskellari organization, so in >>>> case of my absence there are people (Ryan Scott, bodigrim, few others) >>>> who will be able to act. >>>> >>>> Best regards, >>>> Oleg >>>> >>>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lelechenko at gmail.com Tue Feb 16 18:30:43 2021 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Tue, 16 Feb 2021 18:30:43 +0000 Subject: [ANN] bytestring-0.11.1.0 Message-ID: On behalf of maintainers I'm happy to announce that bytestring-0.11.1.0 (http://hackage.haskell.org/package/bytestring-0.11.1.0) is finally released. Highlights from the changelog (https://github.com/haskell/bytestring/blob/0.11.1.0/Changelog.md): * Performance improvements for * strict `map` (up to 30% faster), * strict `pack`, `words`, `intersperse`, `findIndex` and `findIndexEnd`, * lazy `takeWhile`, `dropWhile`, `break`, `group` and `groupBy`, * strict and lazy `stimes`. * New functions: * `compareLength` to compare lengths lazily, * `packZipWith` to zip two `ByteString`, * `findIndexEnd` for `Char8` flavours of `ByteString`, * `elemIndexEnd` and `unzip` for `Data.ByteString.Lazy.Char8`, * `takeEnd` and `dropEnd` for strict `ByteString`. * Improvements for `ShortByteString` * `SBS` constructor is now exposed directly from `Data.ByteString.Short`, * `fromShort` does not reallocate its argument, if it is already pinned. Many people contributed their time and effort to make this release happen. Just to name a few in no particular order, mostly according to `git log`: * Ben Gamari * Callan McGill * Dmitry Ivanov * Eli Kogan-Wang * gutjuri * Jaro Reinders * John Ericson * Moritz Angermann * Simon Jakobi * Sylvain Henry * Viktor Dukhovni * Vincent Orr * me Here is an incantation for `stack` folks: resolver: nightly-2021-02-12 packages: - . extra-deps: - bytestring-0.11.0.0 - binary-0.8.8.0 - directory-1.3.6.1 - text-1.2.4.1 - unix-2.7.2.2 - process-1.6.11.0 allow-newer: true Best regards, Andrew From oleg.grenrus at iki.fi Tue Feb 16 19:02:58 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 16 Feb 2021 21:02:58 +0200 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: Thank you Johan. Could you add me as maintainer on Hackage as well, my username is phadej there as well. Cheers, Oleg. On 16.2.2021 18.59, Johan Tibell wrote: > Done. > > On Tue, Feb 16, 2021 at 5:54 PM Simon Jakobi > > wrote: > > Sounds reasonable to me! > > Am Di., 16. Feb. 2021 um 17:42 Uhr schrieb Oleg Grenrus > >: > > I don't disagree. Having hashable live next to > unordered-containers in > https://github.com/haskell-unordered-containers would be fine > too, if you, David, agree with that. > > - Oleg > > On 16.2.2021 18.37, David Feuer wrote: >> My general view is that it's best for each package (or >> closely allied family of packages) to have its own GitHub >> organization. >> >> On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus >> > wrote: >> >> github.com/haskell is fine >> too. I have uneasy feeling about its current "chaotic >> good" management model though, but I can live with it. >> >> OTOH, you can simply bother me about any package in >> haskellari org. Clear and simple. >> >> - Oleg >> >> On 16.2.2021 17.56, Johan Tibell wrote: >>> I'm not involved anymore so it's fine by me but why >>> not https://github.com/haskell? >>> >>> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus >>> > wrote: >>> >>> I ask to take over the maintenance of hashable, uuid >>> and uuid-types >>> packages. >>> >>> I'm a maintainer of packages depending on them (most >>> notably >>> quickcheck-instances and aeson). >>> >>> I should also mention that when we (Herbert and I) >>> took over Antoine >>> Latter's packages, I took over quickcheck-instances >>> and Herbert took >>> over uuid and parsec. We should taken over together >>> in the first place. >>> >>> My first points of action would be: >>> - make a releases supporting latest versions of >>> dependencies (GHC-9.0, >>> bytestring-0.11) and >>> - move packages to https://github.com/haskellari >>> organization, so in >>> case of my absence there are people (Ryan Scott, >>> bodigrim, few others) >>> who will be able to act. >>> >>> Best regards, >>> Oleg >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Feb 16 19:26:17 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 16 Feb 2021 21:26:17 +0200 Subject: Takeover of hashable and uuid & uuid-types packages In-Reply-To: References: <864093d7-26ca-dbef-1d19-8d761fc8789a@iki.fi> <5d1c9b32-1c9e-3a81-a7ac-585b2c0e6e3e@iki.fi> Message-ID: <6b2d5c2a-01cc-eb92-9563-c0096f63208c@iki.fi> Thank you all for your support. I really appreciate your trust. I'd like to use this opportunity to mention that there are few documentation related issues [1], and I'll welcome patches resolving these. Cheers, Oleg. - [1]: https://github.com/haskell-unordered-containers/hashable/labels/Documentation On 16.2.2021 18.50, Emily Pillmore wrote: > Thanks for taking this on Oleg > > > On Tue, Feb 16, 2021 at 11:43 AM, David Feuer > wrote: > > That would be fine. > > On Tue, Feb 16, 2021, 11:41 AM Oleg Grenrus > wrote: > > I don't disagree. Having hashable live next to > unordered-containers in > https://github.com/haskell-unordered-containers > would be > fine too, if you, David, agree with that. > > - Oleg > > On 16.2.2021 18.37, David Feuer wrote: >> My general view is that it's best for each package (or >> closely allied family of packages) to have its own GitHub >> organization. >> >> On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus >> > wrote: >> >> github.com/haskell is fine >> too. I have uneasy feeling about its current "chaotic >> good" management model though, but I can live with it. >> >> OTOH, you can simply bother me about any package in >> haskellari org. Clear and simple. >> >> - Oleg >> >> On 16.2.2021 17.56, Johan Tibell wrote: >>> I'm not involved anymore so it's fine by me but why >>> not https://github.com/haskell ? >>> >>> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus >>> > wrote: >>> >>> I ask to take over the maintenance of hashable, uuid >>> and uuid-types >>> packages. >>> >>> I'm a maintainer of packages depending on them (most >>> notably >>> quickcheck-instances and aeson). >>> >>> I should also mention that when we (Herbert and I) >>> took over Antoine >>> Latter's packages, I took over quickcheck-instances >>> and Herbert took >>> over uuid and parsec. We should taken over together >>> in the first place. >>> >>> My first points of action would be: >>> - make a releases supporting latest versions of >>> dependencies (GHC-9.0, >>> bytestring-0.11) and >>> - move packages to https://github.com/haskellari >>> organization, so in >>> case of my absence there are people (Ryan Scott, >>> bodigrim, few others) >>> who will be able to act. >>> >>> Best regards, >>> Oleg >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kindaro at gmail.com Tue Feb 16 21:57:20 2021 From: kindaro at gmail.com (Ignat Insarov) Date: Wed, 17 Feb 2021 02:57:20 +0500 Subject: Proposal: Expanding the CLC In-Reply-To: References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> Message-ID: Carter's words touched me. Ever neither smart nor silent, I am going to be a little loud once more. Being an outside spectator of this venue, a beneficiary _(one of innumerably many)_ of the work being inconspicuously done by the persons present, and a skilled developer that potentially may shoulder some of the burden, I would really like to understand better the structure of power and the philosophy behind the CLC enterprise — it is not observable, therefore I cannot decide who to be thankful to and whether my participation is reasonably warranted. I know there are people that do a huge amount of work continuously fixing a vaguely defined cloud of _«core»_ packages — but I also know these people have no idea that I exist, from which it follows that my needs and wishes are respected only accidentally. I am voicing this thought for these reasons: * I am a small scale commercial Haskell user — on its face it classifies me as the target audience. I am invested into Haskell but not a luminary like those others present here — rather an ordinary person, an average. In some way this makes me a representative example. * I am somewhat altruistic. I contribute open source code, answer questions about Haskell and even help people privately without mercantile aims. This suggests that I should want to participate in an effort that is beneficial to many — being an altruist, I may as well be an effective one. If there is a person that should be caught in the wave, that is me here. But it is very evident that I am not. The story is that I asked `\x → (x, x)` to be given a place in standard libraries — hard to find a more innocent proposition. As some know, it did not go well. _(This is not an only example but the most striking.)_ There are several possible explanations. 1. This is meritocracy at work. Haskell collects some of the most gifted programmers of the world. A mere mortal cannot possibly suggest any beneficial change to `base` or `containers` or `vector` or `cabal-install` — in all likelihood it was already considered by the wise council. 2. The philosophy is unclear and undisputed. For example, it was suggested to me in private correspondence that the reason the standard libraries are not being extended more often is because exporting more names is wrong. This is of course as valid a principle as any — but I do not see it being spelled out and considered on the basis of evidence. Perhaps the wizards of code are not that good at other things, like being clear about their design goals. 3. The power structure is set up in favour of a specific invisible group that sets the tune. Recall the story about Stack and Cabal. It had been shown clearly that the interests of the community at large are not represented in the group of maintainers of Cabal. It is hard to triangulate from the distance what exactly went wrong, but on the basis of the meager evidence that I can have, the theory is plausible, and evidence keeps adding up. There is also a question of who selects the libraries to be called _«core»_. For example, Stack _(and, consequently, half the user base of Haskell)_ depends on `rio`, and `typed-process` is a superiour replacement for `process`. Should the _«core»_ include packages vital to half the user base? Should it include a superiour replacement of a morally obsolete package? Or is it a place where leviathans of the past come to die? What does it entail for a package to be considered _«core»_? Does it get included in the standard distribution? What sort of packages should we like to distribute? Finally, there is a question of high principles. Haskell can be a pragmatic tool of the trade or a paragon of elegance, rock-solid or bleeding edge… maybe even all of it at once, but what does the _management_ want it to be? What do you folks dream of? What is your ideal? I cannot see any — I only see reactive efforts to fend off the inevitably approaching future. No one would be inspired by that. I suspect there are a few people that get paid to contribute to Haskell. Maybe that should be the main motive instead? Maybe it is time to say that Haskell is a commercial language maintained by corporate employees? I would not like to be one but at least expectations would be aligned. Haskell has not only made me a programmer — it defined me as a person. There is no other language and no other community like this one. I have reverence. Is it the same for anyone else here? Or should I, rather, grow up and move on? From simonpj at microsoft.com Tue Feb 16 22:54:09 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Feb 2021 22:54:09 +0000 Subject: Proposal: Expanding the CLC In-Reply-To: References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> Message-ID: Ignat Thanks for writing. You are just the sort of person that ought to feel welcome, and able to contribute. That you have not felt that way is a failure. I'd like to suggest another explanation to the three you offer (none of which I subscribe to). 4. The now-very-large Haskell ecosystem runs on the efforts of busy volunteers, all of whom have day jobs. However well-meaning or high-minded we are, things will be left undone, or done less well than we aspire to. I hope and believe that the Haskell Foundation will help with this challenge. I don’t think it'll be a silver bullet. But it should help; and making volunteers such as you feel both welcome and able to contribute meaningfully is certainly a major goal. | Haskell has not only made me a programmer — it defined me as a person.  | There is no other language and no other community like this one. I have | reverence. Is it the same for anyone else here? Or should I, rather, grow | up and move on? Please don't grow up and move on! We are working together to build not just a language to be proud of, but a community we can flourish in. We will stumble for sure, but if we are humble, respectful of each other, and willing to keep trying, I think we can succeed. Simon | -----Original Message----- | From: Libraries On Behalf Of Ignat | Insarov | Sent: 16 February 2021 21:57 | To: Carter Schonwald | Cc: Haskell Libraries | Subject: Re: Proposal: Expanding the CLC | | Carter's words touched me. Ever neither smart nor silent, I am going to | be a little loud once more. | | Being an outside spectator of this venue, a beneficiary _(one of | innumerably many)_ of the work being inconspicuously done by the persons | present, and a skilled developer that potentially may shoulder some of | the burden, I would really like to understand better the structure of | power and the philosophy behind the CLC enterprise — it is not | observable, therefore I cannot decide who to be thankful to and whether | my participation is reasonably warranted. I know there are people that do | a huge amount of work continuously fixing a vaguely defined cloud of | _«core»_ packages — but I also know these people have no idea that I | exist, from which it follows that my needs and wishes are respected only | accidentally. | | I am voicing this thought for these reasons: | | * I am a small scale commercial Haskell user — on its face it classifies | me as | the target audience. I am invested into Haskell but not a luminary like | those | others present here — rather an ordinary person, an average. In some | way this | makes me a representative example. | | * I am somewhat altruistic. I contribute open source code, answer | questions | about Haskell and even help people privately without mercantile aims.  | This | suggests that I should want to participate in an effort that is | beneficial to | many — being an altruist, I may as well be an effective one. | | If there is a person that should be caught in the wave, that is me here.  | But it is very evident that I am not. The story is that I asked `\x → (x, | x)` to be given a place in standard libraries — hard to find a more | innocent proposition. As some know, it did not go well. _(This is not an | only example but the most striking.)_ There are several possible | explanations. | | 1. This is meritocracy at work. Haskell collects some of the most gifted | programmers of the world. A mere mortal cannot possibly suggest any | beneficial change to `base` or `containers` or `vector` or `cabal- | install` — | in all likelihood it was already considered by the wise council. | | 2. The philosophy is unclear and undisputed. For example, it was | suggested to me | in private correspondence that the reason the standard libraries are | not | being extended more often is because exporting more names is wrong.  | This is | of course as valid a principle as any — but I do not see it being | spelled out | and considered on the basis of evidence. Perhaps the wizards of code | are not | that good at other things, like being clear about their design goals. | | 3. The power structure is set up in favour of a specific invisible group | that | sets the tune. Recall the story about Stack and Cabal. It had been | shown | clearly that the interests of the community at large are not | represented in | the group of maintainers of Cabal. It is hard to triangulate from the | distance what exactly went wrong, but on the basis of the meager | evidence | that I can have, the theory is plausible, and evidence keeps adding | up. | | There is also a question of who selects the libraries to be called | _«core»_. For example, Stack _(and, consequently, half the user base of | Haskell)_ depends on `rio`, and `typed-process` is a superiour | replacement for `process`. Should the _«core»_ include packages vital to | half the user base? Should it include a superiour replacement of a | morally obsolete package? Or is it a place where leviathans of the past | come to die? What does it entail for a package to be considered _«core»_?  | Does it get included in the standard distribution? What sort of packages | should we like to distribute? | | Finally, there is a question of high principles. Haskell can be a | pragmatic tool of the trade or a paragon of elegance, rock-solid or | bleeding edge… maybe even all of it at once, but what does the | _management_ want it to be? What do you folks dream of? What is your | ideal? I cannot see any — I only see reactive efforts to fend off the | inevitably approaching future. No one would be inspired by that. I | suspect there are a few people that get paid to contribute to Haskell.  | Maybe that should be the main motive instead? Maybe it is time to say | that Haskell is a commercial language maintained by corporate employees?  | I would not like to be one but at least expectations would be aligned. | | Haskell has not only made me a programmer — it defined me as a person.  | There is no other language and no other community like this one. I have | reverence. Is it the same for anyone else here? Or should I, rather, grow | up and move on? | _______________________________________________ | Libraries mailing list | Libraries at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi- | bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40microso | ft.com%7C7f7bb62c42ac43639d6a08d8d2c5c706%7C72f988bf86f141af91ab2d7cd011d | b47%7C1%7C0%7C637491094192227676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw | MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VxR73 | 6V5TUUf%2B0OfzlBAQK9GG1CpaiBZahvqtiE7obM%3D&reserved=0 From tonymorris at gmail.com Wed Feb 17 03:24:35 2021 From: tonymorris at gmail.com (Tony Morris) Date: Wed, 17 Feb 2021 13:24:35 +1000 Subject: Proposal: Expanding the CLC In-Reply-To: References: <8d36bf94-4556-9600-4220-6e179846b309@obsidian.systems> <9b8acccd-881a-b660-83bb-51b36af467ac@obsidian.systems> Message-ID: I second Simon's words. I didn't read the previous thread, nor will I, so I have no idea what happened with your suggestion. The Haskell Foundation is primed to work toward solving some of the problems with the standard library. FWIW, your suggested operation is a primitive operation of the Extend/Comonad type-class called duplicate, though this is not in the standard libraries. On 2/17/21 8:54 AM, Simon Peyton Jones via Libraries wrote: > Ignat > > Thanks for writing. You are just the sort of person that ought to feel welcome, and able to contribute. That you have not felt that way is a failure. > > I'd like to suggest another explanation to the three you offer (none of which I subscribe to). > > 4. The now-very-large Haskell ecosystem runs on the efforts of busy volunteers, all of whom have day jobs. However well-meaning or high-minded we are, things will be left undone, or done less well than we aspire to. > > I hope and believe that the Haskell Foundation will help with this challenge. I don’t think it'll be a silver bullet. But it should help; and making volunteers such as you feel both welcome and able to contribute meaningfully is certainly a major goal. > > | Haskell has not only made me a programmer — it defined me as a person.  > | There is no other language and no other community like this one. I have > | reverence. Is it the same for anyone else here? Or should I, rather, grow > | up and move on? > > Please don't grow up and move on! We are working together to build not just a language to be proud of, but a community we can flourish in. We will stumble for sure, but if we are humble, respectful of each other, and willing to keep trying, I think we can succeed. > > Simon > > | -----Original Message----- > | From: Libraries On Behalf Of Ignat > | Insarov > | Sent: 16 February 2021 21:57 > | To: Carter Schonwald > | Cc: Haskell Libraries > | Subject: Re: Proposal: Expanding the CLC > | > | Carter's words touched me. Ever neither smart nor silent, I am going to > | be a little loud once more. > | > | Being an outside spectator of this venue, a beneficiary _(one of > | innumerably many)_ of the work being inconspicuously done by the persons > | present, and a skilled developer that potentially may shoulder some of > | the burden, I would really like to understand better the structure of > | power and the philosophy behind the CLC enterprise — it is not > | observable, therefore I cannot decide who to be thankful to and whether > | my participation is reasonably warranted. I know there are people that do > | a huge amount of work continuously fixing a vaguely defined cloud of > | _«core»_ packages — but I also know these people have no idea that I > | exist, from which it follows that my needs and wishes are respected only > | accidentally. > | > | I am voicing this thought for these reasons: > | > | * I am a small scale commercial Haskell user — on its face it classifies > | me as > | the target audience. I am invested into Haskell but not a luminary like > | those > | others present here — rather an ordinary person, an average. In some > | way this > | makes me a representative example. > | > | * I am somewhat altruistic. I contribute open source code, answer > | questions > | about Haskell and even help people privately without mercantile aims.  > | This > | suggests that I should want to participate in an effort that is > | beneficial to > | many — being an altruist, I may as well be an effective one. > | > | If there is a person that should be caught in the wave, that is me here.  > | But it is very evident that I am not. The story is that I asked `\x → (x, > | x)` to be given a place in standard libraries — hard to find a more > | innocent proposition. As some know, it did not go well. _(This is not an > | only example but the most striking.)_ There are several possible > | explanations. > | > | 1. This is meritocracy at work. Haskell collects some of the most gifted > | programmers of the world. A mere mortal cannot possibly suggest any > | beneficial change to `base` or `containers` or `vector` or `cabal- > | install` — > | in all likelihood it was already considered by the wise council. > | > | 2. The philosophy is unclear and undisputed. For example, it was > | suggested to me > | in private correspondence that the reason the standard libraries are > | not > | being extended more often is because exporting more names is wrong.  > | This is > | of course as valid a principle as any — but I do not see it being > | spelled out > | and considered on the basis of evidence. Perhaps the wizards of code > | are not > | that good at other things, like being clear about their design goals. > | > | 3. The power structure is set up in favour of a specific invisible group > | that > | sets the tune. Recall the story about Stack and Cabal. It had been > | shown > | clearly that the interests of the community at large are not > | represented in > | the group of maintainers of Cabal. It is hard to triangulate from the > | distance what exactly went wrong, but on the basis of the meager > | evidence > | that I can have, the theory is plausible, and evidence keeps adding > | up. > | > | There is also a question of who selects the libraries to be called > | _«core»_. For example, Stack _(and, consequently, half the user base of > | Haskell)_ depends on `rio`, and `typed-process` is a superiour > | replacement for `process`. Should the _«core»_ include packages vital to > | half the user base? Should it include a superiour replacement of a > | morally obsolete package? Or is it a place where leviathans of the past > | come to die? What does it entail for a package to be considered _«core»_?  > | Does it get included in the standard distribution? What sort of packages > | should we like to distribute? > | > | Finally, there is a question of high principles. Haskell can be a > | pragmatic tool of the trade or a paragon of elegance, rock-solid or > | bleeding edge… maybe even all of it at once, but what does the > | _management_ want it to be? What do you folks dream of? What is your > | ideal? I cannot see any — I only see reactive efforts to fend off the > | inevitably approaching future. No one would be inspired by that. I > | suspect there are a few people that get paid to contribute to Haskell.  > | Maybe that should be the main motive instead? Maybe it is time to say > | that Haskell is a commercial language maintained by corporate employees?  > | I would not like to be one but at least expectations would be aligned. > | > | Haskell has not only made me a programmer — it defined me as a person.  > | There is no other language and no other community like this one. I have > | reverence. Is it the same for anyone else here? Or should I, rather, grow > | up and move on? > | _______________________________________________ > | Libraries mailing list > | Libraries at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has > | kell.org%2Fcgi- > | bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40microso > | ft.com%7C7f7bb62c42ac43639d6a08d8d2c5c706%7C72f988bf86f141af91ab2d7cd011d > | b47%7C1%7C0%7C637491094192227676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > | MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VxR73 > | 6V5TUUf%2B0OfzlBAQK9GG1CpaiBZahvqtiE7obM%3D&reserved=0 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xFC47318DEB073D0F.asc Type: application/pgp-keys Size: 1696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From alexey.skladnoy at gmail.com Wed Feb 17 10:46:36 2021 From: alexey.skladnoy at gmail.com (Alexey Khudaykov) Date: Wed, 17 Feb 2021 13:46:36 +0300 Subject: Proposal: Expanding the CLC In-Reply-To: References: Message-ID: <0bcecdb5-0e0d-c130-7030-45333bc92f80@gmail.com> 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: From thomas.dubuisson at gmail.com Wed Feb 17 16:54:58 2021 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed, 17 Feb 2021 08:54:58 -0800 Subject: Takeover / Comaintainership of Selda Message-ID: I ask to take comaintainership of the four selda-* packages on hackage. While Anton was active months ago there are fixes that have languished for three weeks. I haven't heard from Anton in over a month, including on my offer to co-maintain a couple weeks back. It isn't my intent to full take over, just help maintain. My first points of action would be: - Merge the three most recent PRs of two critical bug fixes and a clean up. These would have to go on my own fork for the time being. - Release I know 3 weeks is short in the Haskell world for a package takeover. I only want to co-maintain and am ready to wait a while after sending this message in to see if Anton (CCed) awakens. -Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.ericson at obsidian.systems Wed Feb 17 17:34:43 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Wed, 17 Feb 2021 12:34:43 -0500 Subject: Text and changing number primops in GHC 9.2 Message-ID: Hi all, First, background. I have a PR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 that is one of the moving pieces for https://gitlab.haskell.org/ghc/ghc/-/issues/19026 , which is slated for 9.2 according to Ben's email https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html . (I just added the milestone to the issue to reflect this.) Despite this being a breaking change (to unstable interfaces) containers, bytestring, and binary could all updated in a way that didn't used CPP. (See the linked PRs in the GHC !4492's description). Text is a different case, because the unboxed computation there is more pervasive. The current PR is https://github.com/haskell/text/pull/305 , and uses CPP for 9.2. We have a few different options: * Keep as is. There will surely be no perf regressions this way on any of the supported compilers. This does however mean adding CPP for 9.2 before the associated GHC change lands in master. I think that's fine---inevitable even based on the current policy for how GHC submodules are bumped---but it's given many library maintainers the heebie jeebies. * Try the same tricks in the other PRs of using hyper-local unboxing that is easy to unbox away. This will be a bit ugly however than the other cases, and I am not sure whether it won't be a regression for the oldest supported GHCs. * Do the above, but bump the base version to the point where there are no perf regressions with the oldest supported GHCs (because those compilers are no longer supported). If we bump the version more aggressively, perhaps we can get rid of much of the unboxing altogether / otherwise get rid of the ugliness. We'll need to reach some sort of decision here to move forward. I'll also add that while Oleg Grenrus has helped merge a preparatory PR, Oleg expressed a /dis/interest in being de facto text maintainer, so I am emailing the list in part so this does not fall upon Oleg alone any longer. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Feb 17 17:38:21 2021 From: david.feuer at gmail.com (David Feuer) Date: Wed, 17 Feb 2021 12:38:21 -0500 Subject: Text and changing number primops in GHC 9.2 In-Reply-To: References: Message-ID: I still don't understand why GHC is making this change in such a breaky way without even going through the proposal process. On Wed, Feb 17, 2021, 12:35 PM John Ericson wrote: > Hi all, > > First, background. I have a PR > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 that is one of > the moving pieces for https://gitlab.haskell.org/ghc/ghc/-/issues/19026, > which is slated for 9.2 according to Ben's email > https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html. (I > just added the milestone to the issue to reflect this.) > > Despite this being a breaking change (to unstable interfaces) containers, > bytestring, and binary could all updated in a way that didn't used CPP. > (See the linked PRs in the GHC !4492's description). Text is a different > case, because the unboxed computation there is more pervasive. The current > PR is https://github.com/haskell/text/pull/305, and uses CPP for 9.2. We > have a few different options: > > - Keep as is. There will surely be no perf regressions this way on any > of the supported compilers. This does however mean adding CPP for 9.2 > before the associated GHC change lands in master. I think that's > fine---inevitable even based on the current policy for how GHC submodules > are bumped---but it's given many library maintainers the heebie jeebies. > - Try the same tricks in the other PRs of using hyper-local unboxing > that is easy to unbox away. This will be a bit ugly however than the other > cases, and I am not sure whether it won't be a regression for the oldest > supported GHCs. > - Do the above, but bump the base version to the point where there are > no perf regressions with the oldest supported GHCs (because those compilers > are no longer supported). If we bump the version more aggressively, perhaps > we can get rid of much of the unboxing altogether / otherwise get rid of > the ugliness. > > We'll need to reach some sort of decision here to move forward. > > I'll also add that while Oleg Grenrus has helped merge a preparatory PR, > Oleg expressed a *dis*interest in being de facto text maintainer, so I am > emailing the list in part so this does not fall upon Oleg alone any longer. > > John > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.ericson at obsidian.systems Wed Feb 17 18:00:24 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Wed, 17 Feb 2021 13:00:24 -0500 Subject: Text and changing number primops in GHC 9.2 In-Reply-To: References: Message-ID: The way I see it, the primops are an implementation detail of GHC that---unfortunately, but like many others---leaks. If we are to stable interface, it should be a bunch of *un*boxed wrappers in a separate module that make no claims of being the actual primops. It's entirely the conflation of primops / prim types and unboxing that's led to the current unfortunate situation. Also, keep in mind that the precipitating change---that the boxed ones now wrapped the fixed-size types---has already happened, and had to happen to allow the Aarch64 NCG to land. Yes, these primops changes were already being planned, but the urgency for 9.2 is separate, and because we want: * 1 round, and not 2 rounds of breaking changes * changing the primops and types being boxed together in fact leads to *less* breakage overall in many situations. So yes, I hope things can go differently in the future, but slamming the breaks on 9.2 at the last minute to ossify a leaked interface gets us too much of the costs of stabilizing without the benefits. John On 2/17/21 12:38 PM, David Feuer wrote: > I still don't understand why GHC is making this change in such a > breaky way without even going through the proposal process. > > On Wed, Feb 17, 2021, 12:35 PM John Ericson > wrote: > > Hi all, > > First, background. I have a PR > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 > that is > one of the moving pieces for > https://gitlab.haskell.org/ghc/ghc/-/issues/19026 > , which is > slated for 9.2 according to Ben's email > https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html > . > (I just added the milestone to the issue to reflect this.) > > Despite this being a breaking change (to unstable interfaces) > containers, bytestring, and binary could all updated in a way that > didn't used CPP. (See the linked PRs in the GHC !4492's > description). Text is a different case, because the unboxed > computation there is more pervasive. The current PR is > https://github.com/haskell/text/pull/305 > , and uses CPP for 9.2. > We have a few different options: > > * Keep as is. There will surely be no perf regressions this way > on any of the supported compilers. This does however mean > adding CPP for 9.2 before the associated GHC change lands in > master. I think that's fine---inevitable even based on the > current policy for how GHC submodules are bumped---but it's > given many library maintainers the heebie jeebies. > * Try the same tricks in the other PRs of using hyper-local > unboxing that is easy to unbox away. This will be a bit ugly > however than the other cases, and I am not sure whether it > won't be a regression for the oldest supported GHCs. > * Do the above, but bump the base version to the point where > there are no perf regressions with the oldest supported GHCs > (because those compilers are no longer supported). If we bump > the version more aggressively, perhaps we can get rid of much > of the unboxing altogether / otherwise get rid of the ugliness. > > We'll need to reach some sort of decision here to move forward. > > I'll also add that while Oleg Grenrus has helped merge a > preparatory PR, Oleg expressed a /dis/interest in being de facto > text maintainer, so I am emailing the list in part so this does > not fall upon Oleg alone any longer. > > John > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Wed Feb 17 18:05:29 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Wed, 17 Feb 2021 18:05:29 +0000 Subject: Takeover / Comaintainership of Selda In-Reply-To: References: Message-ID: I should hope that if i go on vacation, my packages are not in jeopardy. That seems like a ridiculously short time to wait before trying a takeover. On Wed, Feb 17, 2021 at 11:54 AM, Thomas DuBuisson < thomas.dubuisson at gmail.com > wrote: > > I ask to take comaintainership of the four selda-* packages on hackage. > > > While Anton was active months ago there are fixes that have languished for > three weeks.  I haven't heard from Anton in over a month, including on my > offer to co-maintain a couple weeks back.  It isn't my intent to full take > over, just help maintain. > > > My first points of action would be: > - Merge the three most recent PRs of two critical bug fixes and a clean > up.  These would have to go on my own fork for the time being. > - Release > > > I know 3 weeks is short in the Haskell world for a package takeover. I > only want to co-maintain and am ready to wait a while after sending this > message in to see if Anton (CCed) awakens. > > > -Tom > > > _______________________________________________ > Libraries mailing list > Libraries@ haskell. org ( Libraries at haskell.org ) > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed Feb 17 18:14:06 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 17 Feb 2021 20:14:06 +0200 Subject: Text and changing number primops in GHC 9.2 In-Reply-To: References: Message-ID: I feel I need to clarify. Herbert granted me commit bits to text, so I can do small maintenance tasks on text, to not block GHC release process. However, this change is big and intrusive, and not explained anywhere. There is no wiki page explaining how the primops are changing. I feel I'm forced to accept the PR without having enough information to be able review it. So I will  merge that PR next, but all complaints are regarding possible problems should be directed to GHC maintainers. - Oleg P.S. https://i.imgflip.com/4xebid.jpg On 17.2.2021 20.00, John Ericson wrote: > > The way I see it, the primops are an implementation detail of GHC > that---unfortunately, but like many others---leaks. If we are to > stable interface, it should be a bunch of *un*boxed wrappers in a > separate module that make no claims of being the actual primops. It's > entirely the conflation of primops / prim types and unboxing that's > led to the current unfortunate situation. > > Also, keep in mind that the precipitating change---that the boxed ones > now wrapped the fixed-size types---has already happened, and had to > happen to allow the Aarch64 NCG to land. Yes, these primops changes > were already being planned, but the urgency for 9.2 is separate, and > because we want: > > * 1 round, and not 2 rounds of breaking changes > * changing the primops and types being boxed together in fact leads > to *less* breakage overall in many situations. > > So yes, I hope things can go differently in the future, but slamming > the breaks on 9.2 at the last minute to ossify a leaked interface gets > us too much of the costs of stabilizing without the benefits. > > John > > On 2/17/21 12:38 PM, David Feuer wrote: >> I still don't understand why GHC is making this change in such a >> breaky way without even going through the proposal process. >> >> On Wed, Feb 17, 2021, 12:35 PM John Ericson >> wrote: >> >> Hi all, >> >> First, background. I have a PR >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 that is >> one of the moving pieces for >> https://gitlab.haskell.org/ghc/ghc/-/issues/19026, which is >> slated for 9.2 according to Ben's email >> https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html. >> (I just added the milestone to the issue to reflect this.) >> >> Despite this being a breaking change (to unstable interfaces) >> containers, bytestring, and binary could all updated in a way >> that didn't used CPP. (See the linked PRs in the GHC !4492's >> description). Text is a different case, because the unboxed >> computation there is more pervasive. The current PR is >> https://github.com/haskell/text/pull/305, and uses CPP for 9.2. >> We have a few different options: >> >> * Keep as is. There will surely be no perf regressions this way >> on any of the supported compilers. This does however mean >> adding CPP for 9.2 before the associated GHC change lands in >> master. I think that's fine---inevitable even based on the >> current policy for how GHC submodules are bumped---but it's >> given many library maintainers the heebie jeebies. >> * Try the same tricks in the other PRs of using hyper-local >> unboxing that is easy to unbox away. This will be a bit ugly >> however than the other cases, and I am not sure whether it >> won't be a regression for the oldest supported GHCs. >> * Do the above, but bump the base version to the point where >> there are no perf regressions with the oldest supported GHCs >> (because those compilers are no longer supported). If we bump >> the version more aggressively, perhaps we can get rid of much >> of the unboxing altogether / otherwise get rid of the ugliness. >> >> We'll need to reach some sort of decision here to move forward. >> >> I'll also add that while Oleg Grenrus has helped merge a >> preparatory PR, Oleg expressed a /dis/interest in being de facto >> text maintainer, so I am emailing the list in part so this does >> not fall upon Oleg alone any longer. >> >> John >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.dubuisson at gmail.com Wed Feb 17 20:15:17 2021 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed, 17 Feb 2021 12:15:17 -0800 Subject: Takeover / Comaintainership of Selda In-Reply-To: References: Message-ID: I know, right? I thought I addressed that - happy to wait a few weeks to see if the maintainer comes back on line (that makes it well over a month) and I'm really not looking to be "the" maintainer. For any package that aspires to be used in production it shouldn't be hard to get fixes to critical bugs upstream in weeks and people do deserve vacations so that's why I volunteered to co-maintain. Also, following Oleg's lead, the exact intended actions are included in the request so everyone's clear even when the changes are low volume. On Wed, Feb 17, 2021 at 10:05 AM Emily Pillmore wrote: > I should hope that if i go on vacation, my packages are not in jeopardy. > That seems like a ridiculously short time to wait before trying a takeover. > > > On Wed, Feb 17, 2021 at 11:54 AM, Thomas DuBuisson < > thomas.dubuisson at gmail.com> wrote: > >> I ask to take comaintainership of the four selda-* packages on hackage. >> >> While Anton was active months ago there are fixes that have languished >> for three weeks. I haven't heard from Anton in over a month, including on >> my offer to co-maintain a couple weeks back. It isn't my intent to full >> take over, just help maintain. >> >> My first points of action would be: >> - Merge the three most recent PRs of two critical bug fixes and a clean >> up. These would have to go on my own fork for the time being. >> - Release >> >> I know 3 weeks is short in the Haskell world for a package takeover. I >> only want to co-maintain and am ready to wait a while after sending this >> message in to see if Anton (CCed) awakens. >> >> -Tom >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasufell at posteo.de Wed Feb 17 20:30:08 2021 From: hasufell at posteo.de (Julian Ospald) Date: Wed, 17 Feb 2021 20:30:08 +0000 Subject: Takeover / Comaintainership of Selda In-Reply-To: References: Message-ID: For such cases there's the NMU I believe: https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#3-source-changes-simple-patches On February 17, 2021 8:15:17 PM UTC, Thomas DuBuisson wrote: >I know, right? I thought I addressed that - happy to wait a few weeks >to >see if the maintainer comes back on line (that makes it well over a >month) >and I'm really not looking to be "the" maintainer. For any package >that >aspires to be used in production it shouldn't be hard to get fixes to >critical bugs upstream in weeks and people do deserve vacations so >that's >why I volunteered to co-maintain. Also, following Oleg's lead, the >exact >intended actions are included in the request so everyone's clear even >when >the changes are low volume. > >On Wed, Feb 17, 2021 at 10:05 AM Emily Pillmore >wrote: > >> I should hope that if i go on vacation, my packages are not in >jeopardy. >> That seems like a ridiculously short time to wait before trying a >takeover. >> >> >> On Wed, Feb 17, 2021 at 11:54 AM, Thomas DuBuisson < >> thomas.dubuisson at gmail.com> wrote: >> >>> I ask to take comaintainership of the four selda-* packages on >hackage. >>> >>> While Anton was active months ago there are fixes that have >languished >>> for three weeks. I haven't heard from Anton in over a month, >including on >>> my offer to co-maintain a couple weeks back. It isn't my intent to >full >>> take over, just help maintain. >>> >>> My first points of action would be: >>> - Merge the three most recent PRs of two critical bug fixes and a >clean >>> up. These would have to go on my own fork for the time being. >>> - Release >>> >>> I know 3 weeks is short in the Haskell world for a package takeover. >I >>> only want to co-maintain and am ready to wait a while after sending >this >>> message in to see if Anton (CCed) awakens. >>> >>> -Tom >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed Feb 17 20:33:14 2021 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 17 Feb 2021 21:33:14 +0100 Subject: Takeover / Comaintainership of Selda In-Reply-To: References: Message-ID: Am Mi., 17. Feb. 2021 um 21:19 Uhr schrieb Thomas DuBuisson < thomas.dubuisson at gmail.com>: > I know, right? I thought I addressed that - happy to wait a few weeks to > see if the maintainer comes back on line (that makes it well over a month) > [...] > Regardless of how urgent issues might be for you, I think that a lag of "a few weeks" is totally fine for any project out there maintained by somebody who does this in his spare time. You can be on a longer vacation, be ill for a few weeks, have something urgent things in your family/"real" work, and when you come back you suddenly have a co-maintainer you perhaps don't want? Have a release with some fixes perhaps going in the wrong direction? I would be extremely annoyed by such actions, and I'm sure I'm not alone with this. Doing such harsh measures in such a short time span is probably doing the project more harm than good. If you really need a fix quickly, just fork the project and build from there for a while... Note: The last release of the packages in question is not even a month ago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davean at xkcd.com Wed Feb 17 20:38:48 2021 From: davean at xkcd.com (davean) Date: Wed, 17 Feb 2021 15:38:48 -0500 Subject: Takeover / Comaintainership of Selda In-Reply-To: References: Message-ID: These packages are a community good, but maintained as a community service. It's definitely best practice to have a few maintainers but this isn't the venue. One should contact the existing maintainers directly and ask to become a co-maintainer. Unless the maintainer becomes demonstrably absent it is against policy to interfere in the current maintainers' approach. If a package lacks co-maintainers and/or refuses them, is slow to apply fixes, etc, one should probably fork the package or choose another. The only real exceptions to this are core packages as under the maintenance of the CLC. Anything else would be a discussion about a massive change in policy. -davean On Wed, Feb 17, 2021 at 3:33 PM Sven Panne wrote: > Am Mi., 17. Feb. 2021 um 21:19 Uhr schrieb Thomas DuBuisson < > thomas.dubuisson at gmail.com>: > >> I know, right? I thought I addressed that - happy to wait a few weeks to >> see if the maintainer comes back on line (that makes it well over a month) >> [...] >> > > Regardless of how urgent issues might be for you, I think that a lag of "a > few weeks" is totally fine for any project out there maintained by somebody > who does this in his spare time. You can be on a longer vacation, be ill > for a few weeks, have something urgent things in your family/"real" work, > and when you come back you suddenly have a co-maintainer you perhaps don't > want? Have a release with some fixes perhaps going in the wrong direction? > I would be extremely annoyed by such actions, and I'm sure I'm not alone > with this. Doing such harsh measures in such a short time span is probably > doing the project more harm than good. > > If you really need a fix quickly, just fork the project and build from > there for a while... Note: The last release of the packages in question is > not even a month ago. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Feb 17 21:14:35 2021 From: gershomb at gmail.com (Gershom B) Date: Wed, 17 Feb 2021 16:14:35 -0500 Subject: Proposal: Expanding the CLC In-Reply-To: <0bcecdb5-0e0d-c130-7030-45333bc92f80@gmail.com> References: <0bcecdb5-0e0d-c130-7030-45333bc92f80@gmail.com> Message-ID: <34781033-c0b4-4ea0-b684-04a8e80436b9@Spark> I tend to agree. The CLC is a deliberative body with some action components. (The name “committee” is a tell). One wants those smaller to reach consensus sooner. Having more maintainers for “core” and “near-core” packages (and perhaps formalizing more the latter) is very good. Asking these maintainers be on the CLC doesn’t seem to be necessary to solve any proximate problem? -g On Feb 17, 2021, 5:47 AM -0500, Alexey Khudaykov , wrote: > > I think that we should understand what exactly does CLC do? What should it do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.ericson at obsidian.systems Thu Feb 18 20:19:52 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Thu, 18 Feb 2021 15:19:52 -0500 Subject: Text and changing number primops in GHC 9.2 In-Reply-To: References: Message-ID: <3d938ff8-8325-6646-7975-546b79acade0@obsidian.systems> For anyone that's curious, I've started on https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics which covers: 1. what's planned with "before", "now", and "afterwards" summaries 2. what discussion led us to this point 3. briefly, an accumulation of the problems being addressed I hope this helps, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Mon Feb 22 10:31:35 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 22 Feb 2021 12:31:35 +0200 Subject: Proposal: Add 'Foldable1' to base In-Reply-To: References: <54e2ee88-fb33-67cb-f51b-05be8b6e03e4@gmail.com> Message-ID: <332392c1-4de7-4723-4f8a-5040c22e5abb@iki.fi> The conservative class size is not optimal. One needs at least to have foldrMap-like function. See https://github.com/ekmett/semigroupoids/issues/77 I think that renaming *and* moving to base is better done in one step, as then ecosystem would need to adjust once. A clean approach to migration, which I'd recommend, is to have a (new) compatibility package, because semigroupoids is too heavy, folks don't want to depend on it, even semigroups is heavy for some/ Let's tentatively call it foldable1. Then new base would have the exact same modules as foldable1. And then semigroupoids may at its own pace migrate to use base/foldable1 and the rest of ecosystem would follow. Given that Foldable1 isn't terribly spread class (yet), I don't see that more complicated that what regular major base updates are. There is another reason to have separate package: Bifoldable1, which I argue should be moved to base as well. I think this all is mentioned in my proposal https://oleg.fi/foldable1-proposal3.html I (and also Edward, IIUC) call for CLC to make the choice of naming. The proposal above have three options, I hope one of them fits. - Oleg On 3.1.2021 13.01, George Wilson wrote: > I like David's more conservative class size. > > I would prefer to see the semigroupoids classes renamed [1] before > they get added to base, since it's much harder to rename them once > they're there. However, it's not clear to me that there's the required > will to move forward with such a gargantuan renaming effort > (semigroupoids is depended on directly and transitively by a lot of > hackage). There was a recent attempt that didn't gain traction [2]. I > would also prefer that the renaming and the move to base are two > discrete steps -- not combined, since that would make the migration > awkward and unpleasant (migrating to a differently-named class from a > different package). > > I want to see the spirit of this happen, but overall I'm -1 on this > proposal at this time. > > [1] https://github.com/ekmett/semigroupoids/issues/26 > [2] https://github.com/ekmett/semigroupoids/pull/90 > > Cheers, > George > > > On Fri, 11 Dec 2020 at 22:37, Tony Morris wrote: >> Delete head1 and last1 and you'll get my +1. >> >> (they are better written as optics, when we also get Apply into base) >> >> On 12/10/20 4:37 PM, Reed Mullanix wrote: >>> With the recent discussion around the addition of 'intersection' to containers, >>> I think it might be a good time to re-open the discussion surrounding adding >>> 'Foldable1' to base. >>> >>> For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts >>> folds over non-empty containers. Alternatively, it can be seen as a method >>> of combining together the elements of a container using a semigroup. >>> The contents of this class have been discussed previously (See [1,2]), >>> and the version presented in this proposal is taken from [1]. >>> >>> class Foldable t => Foldable1 t where >>> {-# MINIMAL foldMap1 | foldr1map #-} >>> >>> fold1 :: Semigroup m => t m -> m >>> >>> -- the defining member, like foldMap but only asking for Semigroup >>> foldMap1 :: Semigroup m => (a -> m) -> t a -> m >>> >>> -- strict foldMap1, cf foldMap' >>> foldMap1' :: Semigroup m => (a -> m) -> t a -> m >>> >>> -- analogue of toList >>> toNonEmpty :: t a -> NonEmpty a >>> >>> -- left&right, strict&non-strict folds >>> foldr1 :: (a -> a -> a) -> t a -> a >>> foldr1' :: (a -> a -> a) -> t a -> a >>> foldl1 :: (a -> a -> a) -> t a -> a >>> foldl1' :: (a -> a -> a) -> t a -> a >>> >>> -- these can have efficient implementation for NonEmptySet >>> maximum1 :: Ord a => t a -> a >>> minimum1 :: Ord a => t a -> a >>> >>> -- head1 have efficient implementation for NonEmpty and Tree >>> -- last1 for symmetry >>> head1 :: t a -> a >>> last1 :: t a -> a >>> >>> -- fold variants with premap. >>> -- Without this map, we cannot implement foldl using foldr etc. >>> foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b >>> foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b >>> foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b >>> foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b >>> >>> >>> This has a couple of benefits. On the practical side, we can provide >>> total alternatives >>> to existing partial functions (IE: 'foldr1' and friends). It also >>> enables us to fold >>> over containers using a semigroup instance, which comes up suprisingly often. >>> >>> Naming: >>> -------------------------------------------------------------------------------- >>> Historically, the biggest source of controversy with this proposal has >>> been over the >>> name. The class currently exists in semigroupoids [3] under the name >>> 'Foldable1', though >>> there was some discussion around renaming it to 'SemiFoldable' [4]. >>> However, if we keep >>> the name unchanged, it makes the migration path nice and >>> straightforward, and the possible >>> name conflict with Data.Functor.Classes seems unlikely. >>> >>> Migration: >>> -------------------------------------------------------------------------------- >>> If we decide to go with 'Foldable1' as the name, we should be able to >>> perform this change with >>> 0 breakage. >>> >>> References: >>> [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html >>> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 >>> [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 >>> [4] https://github.com/ekmett/semigroupoids/issues/26 >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries