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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
