RFC: darcs-all improvements?

[Claus Reinke]

>> So I'm asking for comments: if you find these changes useful, and
>> they work for you, perhaps they get included;
>
> I don't build ghc much (but nhc98 has a darcs-all script too...), so

That is exactly why I made those changes. I try to build ghc head
about once a month, which means a lot of patches, lots of build
system changes, lots of things to go wrong (it usually takes a week
before the attempt succeeds). darcs2.0.2 does seem less prone
to making a mess than darcs1.0.9 was, but I still keep verbose logs
of pulls, just in case, and to get an overview of what changed.

Those who pull every day, and only corelibs, have perhaps a page
of darcs output in which to find important messages, less if they don't
care to see what is pulled.

With extralibs, that is closer to two pages. And if there are lots of patches,
it is hopeless, unless you avoid verbose (but then you won't be able to
file darcs bugs reports, and you won't know what kind of patches you
just pulled when the build falls over or ghc's behaviour changes).

> take my opinion with a pinch of salt.  However, I do think both of these
> changes are likely to be improvements: they remove otherwise-puzzling
> behaviour.

Thanks. Btw, configure also gives a lot of detailed output that hides
important information - shouldn't configure also summarize the
important bits at the end? [new ticket -> #2613]

>> - if darcs-all or packages have changed, stop the script and
>>     ask the user to restart the darcs-all command, instead of
>>     continuing with outdated information
>> - try summarizing any darcs warnings (file permission issues, ..),
>>     conflicts, and missing repos at the end of the run, so that
>>     they do not get lost if one keeps a verbose log
>
> Suggestion: this is more likely to be acted on, if you file as a trac
> bug report / enhancement request.

Would you like to file a ticket for that suggestion?-)

Seriously, though, I think of this as a generational memory manager:

1 things that are urgent (all build issues)
    -> email

2 things that are not urgent, but don't require much context
    when acted on [such as my earlier darcs-all suggestions]
    -> email (to be addressed whenever inbox is cleaned up)

3 things that need discussion [such as this one]
    -> email

4 everything else [such as the vague configure suggestion above]
    -> ticket

Emails are first/second generation, tickets are third and higher -
once something has a ticket, it is very close to the eternal generation
(might stay there until _|_).

The advantage of tickets is that things are less likely to get
lost if inboxes get messed up, or if people disagree on urgency.

But, looking at tickets for the current head
http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=version&version=6.9&order=priority

Would it really be useful to clutter that further with small items?
There are already two runhaskell tickets, and a haddock one,
that don't really belong there, imho.

Btw, it might be useful to have a classification (what to report
where wrt ghc head) on the wiki, but since GHC HQ disagrees
with my 1-4 above, it shouldn't be added by me!-)

Claus