Library submission process for tweaks / bugfixes
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
Hi Scott, On Wed, Aug 06, 2008 at 09:51:51AM -0600, Scott Dillard wrote:
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?
If it's a simple bug fix, which doesn't affect the API and just fixes obviously-broken behaviour in the obviously-correct way, then just sending a patch is fine (ideally putting it in trac, so it doesn't get missed). If you're changing the interface or intended behaviour then I think it should go through the library submission process.
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?)
6.10.1 doesn't mean "Cannot be fixed before GHC 6.10.1 is released", but "We want to fix this very soon, and ideally before we release GHC 6.10.1". It takes a few minutes to: * look at the patch and check it looks OK * add a test to the testsuite, if applicable * check it validates, and make any necessary changes if not and, while it is only a few minutes, there are a thousand other things that we need to do that also only take a few minutes, and there are only so many minutes in the day. But if it is in trac then we should get to it. In the particular case of this ticket, I said: It would be very useful if someone could put the datatype invariants as comments in the code. and that would still be very useful for the "look at the patch and check it looks OK" step; it's hard to see if the patch is correct if you don't understand the code!
there is no "libraries/containers" component listed,
Use "libraries (other)".
and many library submissions are flagged "Not GHC" which sounds to me like a dismissal.
"Not GHC" is for tickets that aren't tied to GHC releases, e.g. bugs in extralibs or Visual Haskell. I'm hoping that when the Haskell Platform gets going there will be another bug tracker that we can move the extralibs tickets to, where they might get more attention. If there are any GHC or bootlibs bugs in there then they should probably actually be in _|_ instead. Thanks Ian
participants (2)
-
Ian Lynagh -
Scott Dillard