ANNOUNCE: GHC 6.8.1 Second Release Candidate

[Claus Reinke]

>| - 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