Oh, and if other people think severing is the way to go, I can make the cuts within the next few weeks and take the Data.Sequence chunk. I'd prefer to see other parts maintained by people more familiar with them. On Apr 3, 2016 8:09 PM, "David Feuer" wrote:

Note: the containers package itself would become a dependencies-only shim, perhaps under CLC maintenance. On Apr 3, 2016 8:07 PM, "David Feuer" wrote:

...

I consider myself competent to serve maintain Data.Sequence and Data.Tree. I am much less familiar with the other modules in the package. I would particularly like to serve as co-maintainer if anyone else is interested. Alternatively (and better, in my opinion), the package could be split. Data.Sequence is barely connected to the rest of the package, and the only other module that depends on it doesn't need to. Running under GHC, Data.Graph depends only on Data.Tree (in a hypothetical ST-free system, it also depends on Data.IntSet). So I think it makes sense to have three packages: one for Data.Sequence, one for Data.Tree and Data.Graph, and one for Data.Map, Data.Set, Data.IntMap, and Data.IntSet (which share most of their API and are therefore a sensible package, though generally independent). I see no reason not to divide these three portions among three maintainers. On Apr 3, 2016 7:18 PM, "Milan Straka" wrote:

...

Hi all,

I am writing to let you know that I am no longer able to maintain the containers package.

I have enjoyed working on containers for several years, but I can no longer find the time needed for the job (with two little kids and building a house).

I am not sure what is the best future of the containers package -- it could go to CLC, or it could get a new maintainer. If you look at the commit logs and on the github issues/requests, you will find out that David Feuer has a thorough understanding of the package (notably Data.Sequence) and has been competently moderating the issues/requests for some time now, so he would be the first choice. (I did not contact him sooner, so it is surprise for him as well -- sorry, David :-)

Could I humbly ask David/CLC members/anyone for comments?

Cheers, Milan Straka

Advantages of splitting the package: 1. There can be multiple maintainers with independent release schedules, independent testing and benchmarking code, etc., without stepping on each other's toes or relying on the CLC to make decisions. 2. The containers package does not currently have a unified theme. Instead, it has a somewhat haphazard collection of container types. Four of them (IntSet, IntMap, Set, and Map) really do feel like a package together, and Data.Graph is essentially an extension of/application of Data.Tree. The rest feel quite thoroughly different from each other. Splitting the package would yield three packages that each "make sense" independently. 3. containers is fairly large, and takes a while to build. There might be a way to work around that to make it more convenient to work with individual components, but in light of points 1 and 2, I just don't think it's worth the trouble. On Sun, Apr 3, 2016 at 8:23 PM, Gershom B wrote:

I’m not sure if I see an advantage to severing the packages. I think if David only wants to take responsibility for Sequence and Tree, and then that should be workable regardless, with perhaps the overall package just staying under CLC ownership for now, or perhaps a comaintainer stepping in on the other things. More maintainers for a package tends to be better, to a point, imho.

Cheers, Gershom

On April 3, 2016 at 8:13:52 PM, David Feuer (david.feuer@gmail.com) wrote:

...

Oh, and if other people think severing is the way to go, I can make the cuts within the next few weeks and take the Data.Sequence chunk. I'd prefer to see other parts maintained by people more familiar with them. On Apr 3, 2016 8:09 PM, "David Feuer" wrote:

...

Note: the containers package itself would become a dependencies-only shim, perhaps under CLC maintenance. On Apr 3, 2016 8:07 PM, "David Feuer" wrote:

...

I consider myself competent to serve maintain Data.Sequence and Data.Tree. I am much less familiar with the other modules in the package. I would particularly like to serve as co-maintainer if anyone else is interested. Alternatively (and better, in my opinion), the package could be split. Data.Sequence is barely connected to the rest of the package, and the only other module that depends on it doesn't need to. Running under GHC, Data.Graph depends only on Data.Tree (in a hypothetical ST-free system, it also depends on Data.IntSet). So I think it makes sense to have three packages: one for Data.Sequence, one for Data.Tree and Data.Graph, and one for Data.Map, Data.Set, Data.IntMap, and Data.IntSet (which share most of their API and are therefore a sensible package, though generally independent). I see no reason not to divide these three portions among three maintainers. On Apr 3, 2016 7:18 PM, "Milan Straka" wrote:

...

Hi all,

I am writing to let you know that I am no longer able to maintain the containers package.

I have enjoyed working on containers for several years, but I can no longer find the time needed for the job (with two little kids and building a house).

I am not sure what is the best future of the containers package -- it could go to CLC, or it could get a new maintainer. If you look at the commit logs and on the github issues/requests, you will find out that David Feuer has a thorough understanding of the package (notably Data.Sequence) and has been competently moderating the issues/requests for some time now, so he would be the first choice. (I did not contact him sooner, so it is surprise for him as well -- sorry, David :-)

Could I humbly ask David/CLC members/anyone for comments?

Cheers, Milan Straka

---

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

agreed, containers needs some careful custodianship because of its inclusion in ghc's shipping library set, and the extent to which its used across all known haskell code bases On Sun, Apr 3, 2016 at 10:28 PM, Phil Ruffwind wrote:

Correct me if I'm wrong: my understanding of how Cabal currently works is that if containers becomes a meta-package for other packages (say, containers-map and containers-seq), then users of the package would have to explicitly specify containers-map and containers-seq in the .cabal file. Additionally, to provide compatibility with older versions, there would need to be some sort of conditional logic too. This wouldn't be easy to automate, since one also needs to convert the version bound for containers into corresponding version bounds for the subpackages.

Hence, I think unless there is a way to make it 100% compatible with downstream splitting the package is probably not a good idea, given that containers is such a fundamental package in the ecosystem. Looking at http://packdeps.haskellers.com/reverse , there are about 3000 packages downstream that depend on it (one of highest among the list).

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

On Sun, Apr 3, 2016 at 11:21 PM, David Feuer wrote:

Does Cabal balk if you try to expose a module provided by a dependency? That seems quite strange. If so, could we rename the modules in the splinter packages and then provide modules in the meta-package that just export them wholesale?

I investigated it a bit more closely and it seems I was partly confused by the special case where both the user and the meta-library are part of the same project, e.g. a meta-library A re-exporting an external library B and being used by A's own test suite T. In this special case, the test suite needs to duplicate the dependencies of the meta-library, even if you re-export it under a different module. Fortunately, in the case where the user and the meta-library are compiled as separate projects, the problem is not as bad, hence the workaround you suggested should work:

module Data.Sequence2 where ... -- in a sequence package module Data.Sequence (module Data.Sequence2) where import Data.Sequence2 -- in containers

I don't even think there is a way to expose a module of another package under its own name, is there?

I think we can start with Wren Romano and myself, and ideally add someone to manage Data.Graph sometime later. The question of splitting the package is largely independent. I'd like to see it happen eventually, but it could easily wait several years if that's necessary to avoid problems elsewhere. Further justification for why I want a split, ultimately Milan is right that data structure libraries can consist of unrelated structures, but I think containers is still a bit odd in that so many things are *missing*. I'd expect a data structure library offering the structures containers happens to include to also include more specialized sequence types (e.g. queues, deques, catenable lists, catenable queues, catenable deques), other order-based structures (e.g., priority queues, priority search queues), and probably other things too (tries, perhaps). The selection just seems arbitrary. Making a huge package with all these things a low-level dependency would be awful. So logically, it would seem sensible to divide up the pieces and let packagers bundle the ones they want. If Cabal can't handle this well, then maybe Cabal needs to be fixed. On Apr 6, 2016 4:40 PM, "Milan Straka" wrote:

Hi all,

personally I think that splitting containers has nearly no advantages, but may negatively affect many users, so I am against it. The details follow.

It is true that containers consists of unrelated data structures, but many data structure libraries do, and I do not believe that is should be a reason to split the package. Also I feel that containers are quite small.

From the user point of view, I doubt people would appreciate having more fine-grained versioning of parts of containers. Also note that it is difficult to use other version of containers than the one bundled with GHC (hm, template-haskell used to depend on bundled containers, but at least in 7.10 it does not anymore -- only Cabal, binary, ghc, haskeline, hoopl and hpc does; the situation is better that it used to), so incremental releases of containers between GHC releases have (had?) little use.

From the maintainer point of view, I think building/testing of containers is fine, as the library is pretty small and (at least from my point of view) builds reasonably fast. Moreover, as containers are _widely_ used, I believe we should make as little backward incompatible changes as possible, so bundling releases with GHC releases is fine (and therefore little would be gained from having three smaller packages).

Splitting the package may cause problems -- some people think so, some think that the problems are recoverable -- but still, it is probable that some issues will appear and these may affect a lot of users.

Cheers, Milan

...

-----Original message----- From: David Feuer Sent: 3 Apr 2016, 20:39

1. There can be multiple maintainers with independent release schedules, independent testing and benchmarking code, etc., without stepping on each other's toes or relying on the CLC to make decisions.

2. The containers package does not currently have a unified theme. Instead, it has a somewhat haphazard collection of container types. Four of them (IntSet, IntMap, Set, and Map) really do feel like a package together, and Data.Graph is essentially an extension of/application of Data.Tree. The rest feel quite thoroughly different from each other. Splitting the package would yield three packages that each "make sense" independently.

3. containers is fairly large, and takes a while to build. There might be a way to work around that to make it more convenient to work with individual components, but in light of points 1 and 2, I just don't think it's worth the trouble.

...

I’m not sure if I see an advantage to severing the packages. I think if David only wants to take responsibility for Sequence and Tree, and then

On Sun, Apr 3, 2016 at 8:23 PM, Gershom B wrote: that should be workable regardless, with perhaps the overall package just staying under CLC ownership for now, or perhaps a comaintainer stepping in on the other things. More maintainers for a package tends to be better, to a point, imho.

...

Cheers, Gershom

On April 3, 2016 at 8:13:52 PM, David Feuer (david.feuer@gmail.com)

...

...

Oh, and if other people think severing is the way to go, I can make

...

...

cuts within the next few weeks and take the Data.Sequence chunk. I'd

...

...

to see other parts maintained by people more familiar with them. On Apr 3, 2016 8:09 PM, "David Feuer" wrote:

...

Note: the containers package itself would become a dependencies-only shim, perhaps under CLC maintenance. On Apr 3, 2016 8:07 PM, "David Feuer" wrote:

...

I consider myself competent to serve maintain Data.Sequence and Data.Tree. I am much less familiar with the other modules in the

...

...

...

...

would particularly like to serve as co-maintainer if anyone else is interested. Alternatively (and better, in my opinion), the package could be split. Data.Sequence is barely connected to the rest of the

...

...

...

...

the only other module that depends on it doesn't need to. Running under GHC, Data.Graph depends only on Data.Tree (in a hypothetical ST-free system, it also depends on Data.IntSet). So I think it makes sense to have three packages: one for Data.Sequence, one for Data.Tree and Data.Graph, and one for Data.Map, Data.Set, Data.IntMap, and Data.IntSet (which share most of their API and are therefore a sensible package, though generally independent). I see no reason not to divide these three portions among three maintainers. On Apr 3, 2016 7:18 PM, "Milan Straka" wrote:

> Hi all, > > I am writing to let you know that I am no longer able to maintain

...

...

...

...

> containers package. > > I have enjoyed working on containers for several years, but I can no > longer find the time needed for the job (with two little kids > and building a house). > > I am not sure what is the best future of the containers package -- it > could go to CLC, or it could get a new maintainer. If you look at

...

...

...

...

> commit logs and on the github issues/requests, you will find out

wrote: the prefer package. I package, and the the that

...

...

...

...

> David Feuer has a thorough understanding of the package (notably > Data.Sequence) and has been competently moderating the issues/requests > for some time now, so he would be the first choice. (I did not contact > him sooner, so it is surprise for him as well -- sorry, David :-) > > Could I humbly ask David/CLC members/anyone for comments? > > Cheers, > Milan Straka >

---

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

On 2016-04-04 at 02:09:26 +0200, David Feuer wrote:

Note: the containers package itself would become a dependencies-only shim, perhaps under CLC maintenance.

...that might sound good at first, but you'd want to use Cabal 1.22+ module-reexport feature otherwise you're forced to use PackageImports when you depend on both 'containers' and one of the sub-packages. making a shim-package 'containers' would require to have rather tight bounds to satisfy the PVP, because as soon as you re-export dependencies' modules/APIs, you get into the transitive-dependency API leakage problem. So at the very least you'd need to use minor-version bounds, as otherwise you'd violate the PVP for the containers package. Moreover, a containers version 0.6.0.0 would still have a bit of wiggle room as it re-exposes an API from its own depdencenies which is only defined up to the patch-level. Maybe there's a problem with containers-graph 0.6.0.0 and for some reason you need 0.6.0.2 or later, so now you'd need to depend on both 'containers == 0.6.*' and 'containers-graph >= 0.6.0.2 && < 0.6' Moreover, the shim-package 'containers' would have to have to bump its minor version number each time a new minor version number of one of its sub-packages is released, while keeping single-minor-version-range constraints on its sub-packages. TLDR: PVP & re-exporting modules/APIs quickly leads to a huge mess and is therefore best avoided if possible.

On Sun, Apr 3, 2016 at 8:07 PM, David Feuer wrote:

I consider myself competent to serve maintain Data.Sequence and Data.Tree. I am much less familiar with the other modules in the package. I would particularly like to serve as co-maintainer if anyone else is interested.

I consider myself competent to maintain Data.IntMap, Data.IntSet, Data.Map, and Data.Set. Albeit, I haven't looked too closely at any changes since the end of Milan Straka's major overhaul for micro-optimizing things a while back; but I'm very familiar with the structures themselves and how/why they work the way they do. However, until this fall I am extremely busy so I wouldn't feel comfortable making people rely on my timeliness. I would be fine becoming a co-maintainer once autumn rolls around, though.

Alternatively (and better, in my opinion), the package could be split.

I leave that decision to the wisdom of the list. -- Live well, ~wren

Just to add my 2c to the "to split or not to split" topic: Please do not split such a fundamental package! As already mentioned, it is the 2nd most used package on Hackage (only slightly behind "bytestring" and ignoring "base"). Even making tiny incompatible changes will immediately break hundreds, if not thousands of packages on Hackage. If this is really planned, there should be an extremely good reason for it, and I can't see one: The package is very small and there is almost no activity in the repository (https://github.com/haskell/containers/graphs/commit-activity), so maintenance burden can't be a valid reason for splitting. And even if it one wants to split, there are lots of orthogonal aspects of containers: lazy/strict, order-based/hash-based, set/map/multimap, sorted/unsorted variants, catenable or not, etc. Which of these should be the splitting criterion? The extreme of putting each data structure into its own package seems to be a little bit excessive. OTOH I'm all for adding missing functionality to "containers", at least if they don't introduce incompatible changes. Of course one can add additional packages with subsets of "containers", keeping the latter untouched. If most Hackage authors switch to the new packages, "containers" can be phased out. But even if that happens (which I doubt), this will take quite a few years. Cheers, S.

I also hope splitting containers would not be done lightly. Recently network-uri was split out of network, and even though people thought very hard about this, there were problems, and people had to change their cabal files. I don't really see the advantages as very big (you can have multiple maintainers on a single package, the build times aren't that long and generally you don't build it often anyway, and I'd say the theme is "containers" :)) and like others have said, any small breakage will affect lots of packages. So please carefully consider if the advantages outweigh the risks before taking this action. There are other costs to splitting up packages; it is not free. Cabal dependency resolution will be slower, you'll have to add more things to your cabal file, stack.yaml, etc. We don't want to end up in the node.js situation with single function packages. Erik On 8 April 2016 at 09:10, David Feuer wrote:

Just to be clear: no one is looking to make major breaking changes to containers. If it is split, it will have to be done in such a way that people depending on it won't even notice, except by watching Cabal build messages flash by. If that's not currently possible, then I don't think *anyone* would want to split it now.

On Apr 8, 2016 3:05 AM, "Sven Panne" wrote:

...

Just to add my 2c to the "to split or not to split" topic: Please do not split such a fundamental package! As already mentioned, it is the 2nd most used package on Hackage (only slightly behind "bytestring" and ignoring "base"). Even making tiny incompatible changes will immediately break hundreds, if not thousands of packages on Hackage. If this is really planned, there should be an extremely good reason for it, and I can't see one: The package is very small and there is almost no activity in the repository (https://github.com/haskell/containers/graphs/commit-activity), so maintenance burden can't be a valid reason for splitting. And even if it one wants to split, there are lots of orthogonal aspects of containers: lazy/strict, order-based/hash-based, set/map/multimap, sorted/unsorted variants, catenable or not, etc. Which of these should be the splitting criterion? The extreme of putting each data structure into its own package seems to be a little bit excessive.

OTOH I'm all for adding missing functionality to "containers", at least if they don't introduce incompatible changes.

Of course one can add additional packages with subsets of "containers", keeping the latter untouched. If most Hackage authors switch to the new packages, "containers" can be phased out. But even if that happens (which I doubt), this will take quite a few years.

Cheers, S.

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