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