The libraries proposal process and containers

[Simon Peyton-Jones]

|  All these things do not touch API. The performance patches have
|  benchmark results on them.
|  
|  I pushed hastily as I wanted to sort out the INLINE => INLINABLE issue
|  and I was working on the top of my repo with all these performance
|  changes.

Let's not go overboard here.  OK, Milan didn't do the Right Thing, but:

* It's GREAT that he has taken the time to improve the containers library.
   It's used by lots of people, so the benefits will be widely felt.  But it takes
   painstaking work to find make solid performance improvements.  Thank
   you Milan!  We need more people like you.

* Most if not all of the changes relate to performance and not API.
   And the last patch (itself pushed over-hastily by Simon M) had some negative
   impact on code size that we've been keen to see rectified in time for
   the GHC release.  (There is still time; we are only at release candidate
   stage.)

* The maintainer of 'containers' is libraries at haskell.org, so I don't think
   it's true to say that Milan isn't the maintainer. As I understand the 
   protocol for such packages, one makes a proposal, and if there 
   is no dissent, one pushes it.

I am agnostic about how to proceed from here.  We could roll back all the patches (Milan's and the previous one that Simon M pushed).  Or we could move on from here.

So don't feel bad, Milan.  Incidentally, do you have any more performance improvement in the pipeline?

Simon