Re: Library proposals

On Fri, Dec 10, 2010 at 01:57:59PM +0100, Johan Tibell wrote:

On Fri, Dec 10, 2010 at 12:38 PM, Ross Paterson 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