ANNOUNCE: GHC 6.8.1 Second Release Candidate

[Claus Reinke]

Hi Simon,

>That's true.  As Simon mentioned, the Trac people know this too 
>and plan to fix it. When they do, we'll use the 'Status' field (which 
>is the Right Thing but currently un-configurable) to track workflow.
>We'll probably try to keep it very simple though.

see my reply to Simon's message.

>| - 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
>As you know, we are heads-down getting 6.8 out. 
>Once it's out, we'll get back to triaging.

i must be misunderstanding what you mean by "triaging":
how can you decide whether 6.8 is ready to go out without
looking at the tickets to see which ones do or do not have
to go in?

>I know of one patch from you (the one that Simon has tested 
>a couple of times), but I don't know of two others. Perhaps 
>we have missed them: can you point to their tickets?

the first one was :browse!, which hasn't seen anything but
cosmetic changes and test workarounds (for issues with
the existing :browse, not specific to my patch) since you 
reviewed it over a month ago. since the next two patches
(multiline commands and extended :set/:show) affected
the same file, and the first hadn't been applied, i merged 
all three to keep darcs trouble small.

>| the various, mostly non-technical delays, combined with 
>|the various non-problem-specific hurdles, sent me a clear 
>|message of  "don't bother".
>
>I'm very sorry that that's the message you received.  It 
>obviously isn't the message we are trying to transmit!  The 
>various non-technical obstacles include writing documentation, 
>generating tests, and ensuring that the patch passes validation. 

writing documentation or tests is a technical obstacle. non-
technical (or at least, non-patch-related) obstacles are things
like darcs partial not working, ghc head not building, validate
not working on win/xp, patch emails getting delayed waiting 
for moderator approval, validation failing on other platforms
and having to wait a week before hearing that and another 
week before getting the actual test logs, etc.).

perhaps i'll write the story of these patches some day, for
your amusement. after they make it into head.

>Incidentally, in direct response to your earlier suggestion I 
>did write up the workflows.  Follow this link and the look 
>at the "How to fix a bug" and "How to add a feature" links.
>        http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions

useful. though, as with all documentation, making the next
move obvious and simple is much better than the very best 
documentation - if it needs documentation to be written 
and read, it is too complicated. and every new piece of 
documentation and regulation makes the jungle a little less
traversable.

>If you have suggestions for improving them, do let us know.

one immediately springs to mind: do not assume that 
because each individual barrier seems easy and necessary
that they are not problematic for others, individually or
piled up (validate takes more than an hour on my laptop,
non-partial repos are out of the question over a slow
phone line, even pulling partially takes ages, without
even saturating the slow line [yesterday, i saw network
usage going from under 50% down to under 10% while
doing pull -a], recording often with partial repos is a 
recipe for disaster with darcs, even recording/unrecording
once takes some fragile trickery,..).

another suggestion: the spirit is more important than the
letter. the purposes of things like testsuite and validate is
(1) to make sure that patches don't break anything, and
(2) to make sure that patches do something useful.

validate doesn't guarantee either, and failing validate
on some platform doesn't mean that the patch is at
fault. if the patch implements a feature you've agreed
is useful, and doesn't break anything, applying it and
then asking for improvements would be better than
sending it back as a whole (if only to save me from 
darcs). especially if validate failure is not due to the
things the patch implements.

easier access to validate results on all buildbots would
be helpful. currently, i validate on my platform, ignore
the failures not caused by my own patches, send them,
wait for you to apply them and give me feedback. when
you get around to it, you find there is a typo/platform 
issue and send everything back to me.

if i could email patches to a buildbot address, with 
buildbots applying and validating them, making
build/test results and full validate log available to
me, without applying these patches to the main repo,
i coud make faster progress without having to
bother you at every step.

claus