Hi, The library submission process wiki page says to create a ticket and post it to the list when proposing interface changes, but what is the proper method for submitting bug fixes and tweaks? This post is both an inquiry into the library patching process, and a friendly reminder of some outstanding submissions of mine. I'm watching http://darcs.haskell.org/packages/containers and I don't see anything related to the following : 1) There is an egregious and program-breaking typo, already patched and languishing on trac : http://hackage.haskell.org/trac/ghc/ticket/2359 . IMO that needs to be pushed right now. (milestone 6.10? Whats the point of a separate containers repo?) 2) Months ago I submitted a small patch to fix a too-restrictive type signature : http://www.haskell.org/pipermail/libraries/2008-May/009677.html 3) and another to improve performance of findMin / findMax : http://www.haskell.org/pipermail/libraries/2008-May/009687.html 4) and another, with the help of Bertram F, to improve the runtime complexity of fromAscList for IntSet and IntMap : http://www.haskell.org/pipermail/libraries/2008-May/009685.html I was hoping for some kind of binary response, "ok, pushed" or "no thanks." I have more of these kinds of changes that I plan on making. Whom do I email? Should I use all caps or what? :) Clearly its not sufficient to say "propose interface changes on trac, post bugfixes to the list" because either no one with push power is reading the list, or they get their "to do" items from trac only. Which is something of a problem, because a mailing list can't generate "to do" items. On trac someone with access rights flags a ticket, but nothing like that happens on the list. And even if the proper place for submissions is trac, there is no "libraries/containers" component listed, and many library submissions are flagged "Not GHC" which sounds to me like a dismissal. Is containers still "GHC"? As I understand it, containers is a free-standing project and this list is its collective maintainer. (Which I don't really see as a solution.) Scott