Library submission process for tweaks / bugfixes

[Ian Lynagh]

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