Library proposals

[Ian Lynagh]

On Fri, Dec 10, 2010 at 01:57:59PM +0100, Johan Tibell wrote:
> On Fri, Dec 10, 2010 at 12:38 PM, Ross Paterson <ross at soi.city.ac.uk> wrote:
> > A fair number of people, including you and I, have commit access.
> > There is nothing to stop any of us from cleaning up the code, writing
> > tests or polishing documentation, and most of us would be happy to commit
> > such changes from occasional contributors.
> 
> But it doesn't happen (to any large extent). We should ask ourselves
> why that is. Perhaps it's because since so many people are
> "responsible" (i.e. have commit access), no one feels responsible for
> the overall heath/design of the library.

Perhaps a good compromise would be for each package to have a
maintainer, but for API changes to continue to use the current library
process?

That way there is a greater chance that someone will be doing the
gardening, and they will be more motivated to ensure that proposals
reach a conclusion, but for API changes the community will not be
surprised by functions disappearing, appearing or changing.

> > The only thing the current setup prevents us from doing is changing
> > interfaces without getting wider agreement -- I think that's a feature.
> 
> I'm not sure I agree. For example, IntMap didn't have strict versions
> insert and insertWith, making it practically impossible (due to crap
> performance) to efficiently keep an IntMap where the value was a
> counter of any kind (e.g. an Int). That took 4 months to fix as fixing
> it involved an API addition. FOUR MONTHS. If it had been my library it
> would have taken five minutes.

I think that gives an extremely misleading impression of how the process
works.

The first 2 weeks were required by the process, to give the community
time to comment.

It then took you 3 weeks to add "No objections within 5 weeks." to the
ticket.

After that, someone was working on fixing performance regressions in the
package, and I didn't want to muddy the waters by pushing more changes
into the package; like I said:

    > Could you please wait for the patches referrer to in #4257 and
    > #4278 to make it into the repo. They should be committed as soon
    > as Ian has time to look at them.

    I won't be pushing any container patches until the existing
    performance issue is resolved, either by fixing the regressions or
    by rolling back all the recent patches.

I wouldn't have pushed them if I'd been the maintainer either.

I also don't think the actual amount of time a patch takes to hit the
repo is that important for the GHC boot libs, as to a large extent the
only thing that matters in practice is which GHC major release they fall
into.

> Lets look at it another way, since the libraries maintained by
> libraries@ have a stricter process for API changes, they ought to have
> a better API than the ones that are maintained outside the process,
> right? At least in my opinion, the best libraries are all outside the
> libraries@ process: bytestring, binary, text, etc.

Those three have barely been "maintained" at all: They were recently
designed as complete libraries (albeit as a rewrite in bytestring's
case), rather than being the result of many years worth of accumulated
code.

Other old, core libraries which have had a maintainer in the past (e.g.
Win32) haven't radically improved, as far as I can remember.


Thanks
Ian