Hi Claus, On Wed, Oct 17, 2007 at 04:19:03PM +0100, Claus Reinke wrote:

...

The 6.8.1 release is very close now. We only intend to look at the bugs listed here:

http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority

- the list of outstanding issues for 6.8 branch is suspiciously long. has this been reviewed in detail?

There are always more bugs and performance issues that could be fixed, but at some point we need to draw a line and make a release, or else we never will! We don't think that there is anything critical missing from the above list, but it's possible that either we've overlooked something, or there is something that is critical to some people but we haven't realised how important it is. Of course, we can't guarantee to fix everything that people raise (or we'd be back to never releasing), but if something jumps out at you please let us know and we will look at it. Thanks Ian

| - the list of outstanding issues for 6.8 branch is suspiciously long. has | this been reviewed in detail?

Good point, Claus. Lots of people are using GHC for lots of things. This is a nice problem to have! But it does lead to lots of bug reports. We have limited resources, so we have to decide how best to spend them. In this case we have not reviewed the 6.8 list "in detail" because we thought it was more important to fix the ones that we knew were important.

i tried to explain my concerns to Ian off-list, but i'll make another attempt here, adding some related points about the tracker that have been on my mind for a while now. sorry if that make this reply longer, but i think the points are important (i would think that, wouldn't i?-). as usual, please understand that i hope this criticism may help you to get more out of your efforts, which i appreciate as much as others do: - people submit bugreports because they hope something is done about them; ideally, that something would be a fix, but with limited resources, that isn't always possible - i understand; what should be possible, though, is to let everyone know where each ticket stands, what is going to happen when, and that it hasn't just been forgotten - your previous habit of going through all tickets when a release comes up, and either assigning them or moving their milestone, was reassuring - one might disagree with your decisions, but at least nothing was forgotten, and it was clear what happened; my main suggestion was _not_ to abandon that habit for this and future releases. - the longer tickets stay in the tracker, the more tickets there'll be, the more difficult it will be to find the "important" ones, and the more difficult it will be to ensure that things don't fall by the wayside (noone bothers to report things they do not find important); the number of tickets in the tracker is not just a function of users vs resources, it is also affected by the way workflows are organised, and the efficiency of the tracker in supporting such organisation if you try to go through all tickets even briefly, i hope you'll agree with the following: - the current tracking system is not set up efficiently: one cannot tell the state of play just by looking at a ticket, but has to delve into the comments instead; in brief, trac is still mostly tracking tickets, instead of tracking the state of work in a workflow. just from looking at a ticket (not its description/history), it should be clear what its status is, what the next action is (need not be fix/merge, but could be: getting a testcase, clarifying an issue, looking up some specs, consulting some expert, waiting for a buildbot donation, waiting for a volunteer, ..; anything that explains what is holding things up), who's responsible for that next action (might be the submitter, the assignee, or a third party), what the deadline for that next action is (so people can make plans and decisions), and what is going to happen afterwards (so that everyone can see the intended workflow). the current system tells me none of that, it only tells me at what milestone the ticket will next be reviewed, and you're about to abandon even that guarantee. - clearing mostly fixed tickets away completely saves time and effort, delaying them creates extra work and clogs up the tracker - having whole groups of tickets without any milestone, or with obsolete milestones, stongly suggests that the tracker has passed its limits of useability and needs to be looked into as a matter of urgency before things get worse

We also started the "add yourself to the cc list" mechanism, to enable the community to say which bugs are important to them.

is there a query that lists tickets in priority order? also, each ticket should include its priority ranking and a text saying: "add yourself to the cc list if you want to raise this ticket". other suggestions for the tracker: adding more status/next action/deadline/actor fields would help, if trac supports that (could be simple free-form text fields, or selections), and adding an email interface, so that you can simply forward an email to the tracker if you know your todo list is already full, to get back an issue/ ticket number (a lot better than to tell the sender to go away and submit a ticket, btw; you could initialise the ticket with the email, then ask the sender to fill in the details; there could be bugs-ghc-head@ and bugs-ghc-release@). also, if you want to increase the use of the tracker for patches, there needs to be a document flow (submitter sends patch for review, assignee reviews and returns comments, submitter updates patch, submitter adds tests, assignee takes over patch, assignee validates/ applies to head, release maintainer takes over patch, etc), not just attachments to tickets. it needs to be obvious not only what files there are, but what files there should be, and who is doing what with them when. again, all of this should be in the formal part of the ticket, visible at a glance, not buried in the ticket history and discussion.

| several of the tickets look more or less | fixed, and there seems to be nothing standing in the | way for fixing some more, such as this one: | http://hackage.haskell.org/trac/ghc/ticket/1226

We would absolutely love help from you or anyone else to verify that the ones that are more or less fixed are indeed fixed; and to fix ones for which there is nothing standing in the way.

please don't get me started on this!-) the reason i noticed that the tracking system is in a bad state is because i did contribute solutions, and recorded them in tickets, but nothing seems to happen with those tickets; or i report issues, they get assigned to milestones that then disappear (6.6.2) and nothing else happens (no action, not even a comment). i've also been trying to contribute three patches over the last two months, and they are still not in; the various, mostly non-technical delays, combined with the various non-problem-specific hurdles, sent me a clear message of "don't bother". in all this time, less than a week was spend on technical issues with the patches themselves, the rest was extraneous. we're now getting to discuss final technical details at last, and i intend to see these patches through, but i'll think more than twice before sending any new ones. then i switched to submitting code without patch, in the hope that this would help to resolve tickets that are important to me, such as #1226; as far as i can tell, that ticket could then have been fixed in 5-10 minutes, but nothing happened, and the "6.8 branch" is very unspecific about when anything will. i also don't think that the ticket reflects the implementation status (hasn't the windows issue reported there been fixed yet?). i hope this helps, and thanks again for your efforts, claus

Claus Reinke wrote:

adding more status/next action/deadline/actor fields would help, if trac supports that (could be simple free-form text fields, or selections),

FYI, Trac is bringing us "customised workflows", which will allow us to do some of this: http://trac.edgewall.org/wiki/WorkFlow In particular we'll be able to add new ticket states to indicate that the ticket is waiting for feedback from the submitter, or some other dependency. I wouldn't be in favour of just adding new fields to do this right now, we already have too many fields. Cheers, Simon

Hi On 10/24/07, Ian Lynagh wrote:

Hi,

On Wed, Oct 24, 2007 at 09:28:51AM +0200, Jean-Philippe Bernardy wrote:

...

I ran into this problem with the GHC API (GHC 6.8.1 Second Release Candidate)

upon doing:

session <- GHC.newSession (Just path)

I run into:

yi: Can't find package.conf as /home/jp/usr//lib/ghc-6.8.0.20071019 /driver/package.conf.inplace

Thanks for the report; however, I can't reproduce this.

Somehow I got a carriage return inserted in the libdir that I passed to newSession. So the only problem on GHC side is that the error message is slightly misleading. (Nothing to worry about I would say) Thanks -- JP