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