I can no longer maintain containers

Wed Apr 6 21:12:12 UTC 2016

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" <milan at strakovi.com> 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 <david.feuer at gmail.com>
> > 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.
> >
> > 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
> > >>
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160406/d6c0991b/attachment-0001.html>