Announcing the GHC Bug Sweep
Help us weed the GHC ticket database, and get a warm fuzzy feeling from contributing to Haskell core technology! There are currently ~750 tickets against GHC. Many of them have not been looked at in months or years. Often when I go through old tickets I find easy targets: bugs that have already been fixed, duplicates, bugs that are not reproducible and the submitter has gone away. So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least. This is a game for the whole family! We don't care how much progress you make on each ticket, just as long as someone has taken a look and moved the ticket forward in some way. For example, you might check for duplicates, update the metadata, ask for more information from the submitter, try to reproduce the bug against the latest version of GHC. To claim a ticket all you have to do is remove it from the list on the wiki. Full instructions are here http://hackage.haskell.org/trac/ghc/wiki/BugSweep including a list of suggestions for ways to make progress on a ticket. Cheers! Simon & the GHC team
Cool, I'm in! (Also inspired by [1]this post by Erik de Castro Lopo)
It would be nice to keep track of participants somewhere, so that each
of us knows he's not alone :)
1. http://www.mega-nerd.com/erikd/Blog/CodeHacking/DDC/hacking_ddc.html
* Simon Marlow
Help us weed the GHC ticket database, and get a warm fuzzy feeling from contributing to Haskell core technology!
There are currently ~750 tickets against GHC. Many of them have not been looked at in months or years. Often when I go through old tickets I find easy targets: bugs that have already been fixed, duplicates, bugs that are not reproducible and the submitter has gone away.
So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least.
This is a game for the whole family! We don't care how much progress you make on each ticket, just as long as someone has taken a look and moved the ticket forward in some way. For example, you might check for duplicates, update the metadata, ask for more information from the submitter, try to reproduce the bug against the latest version of GHC.
To claim a ticket all you have to do is remove it from the list on the wiki. Full instructions are here
http://hackage.haskell.org/trac/ghc/wiki/BugSweep
including a list of suggestions for ways to make progress on a ticket.
-- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain
So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least. What I'd really like to see is a kind of categorization according to
Hello, I'm also interested and find Roman's idea about a wiki-page for tracking motivating. the topic, difficulty etc.... I think determing these things could be quite difficult for a GHC newbie (e.g. me). Any plans to do this? Kind regards, Michael -- Dipl.-Inf. Michael C. Lesniak University of Kassel Programming Languages / Methodologies Research Group Department of Computer Science and Electrical Engineering Wilhelmshöher Allee 73 34121 Kassel Phone: +49-(0)561-804-6269
On 16/11/2009 22:32, Michael Lesniak wrote:
Hello,
I'm also interested and find Roman's idea about a wiki-page for tracking motivating.
So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least. What I'd really like to see is a kind of categorization according to the topic, difficulty etc.... I think determing these things could be quite difficult for a GHC newbie (e.g. me). Any plans to do this?
If you go to the "Custom Query" section of Trac, you can do these kinds of searches. The field "Component" is for the part of the system that the ticket applies to (e.g. compiler, run-time system, build system etc.), and "Difficulty" is a rough idea of how much work is involved. Obviously the difficulty varies a lot depending on who is doing the work, which is why I say it's a rough idea. These fields aren't always set correctly, which is one of the things that we hope to improve with the bug sweep. Cheers, Simon
On 16/11/2009 16:29, Simon Marlow wrote:
Help us weed the GHC ticket database, and get a warm fuzzy feeling from contributing to Haskell core technology!
There are currently ~750 tickets against GHC. Many of them have not been looked at in months or years. Often when I go through old tickets I find easy targets: bugs that have already been fixed, duplicates, bugs that are not reproducible and the submitter has gone away.
So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least.
This is a game for the whole family! We don't care how much progress you make on each ticket, just as long as someone has taken a look and moved the ticket forward in some way. For example, you might check for duplicates, update the metadata, ask for more information from the submitter, try to reproduce the bug against the latest version of GHC.
To claim a ticket all you have to do is remove it from the list on the wiki. Full instructions are here
http://hackage.haskell.org/trac/ghc/wiki/BugSweep
including a list of suggestions for ways to make progress on a ticket.
Thanks to all those who have helped out so far. The bug database now has fewer bugs than a couple of days ago (we're now at 738). It's not much, but we're heading in the right direction. Cheers, Simon
participants (3)
-
Michael Lesniak -
Roman Cheplyaka -
Simon Marlow