I can no longer maintain containers

[David Feuer]

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 <gershomb at gmail.com> 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 at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>