Thanks for all the work you are doing on GHCi. It's great to have help on
making it more usable.
it is nice to see GHCi evolving (definitely beyond catching-up-with-hugs
now!-) i just happened to be in the area after implementing :browse!, so
i looked into multiline commands and :set/:show as well (those had been
on my wish list for a while, and your other useful additions to GHCi now
made them urgent, i felt). i look forward to seeing them all in a release
version soon (provided you agree with the way i did them).
We are using Trac much more systematically now, to try to avoid
letting something fall through the cracks. So here's a suggestion:
could you in future create a Trac task or feature request for each
(non-trivial) activity? That way
- you can use the ticket to propose your new feature, before you
implement it, so that others can comment on the specification
- you can attach your Darcs patch to the ticket, so that we don't
lose track of it (e..g forget to review of commit it).
Does that make sense? I'll update the guidelines to suggest this
(we've only just thought it out really).
it used to be the rule that head-related bugs/discussions go to the
cvs-ghc list, not the ghc-{users,bugs} lists, and trac reports to
ghc-bugs. either you need to change that separation, or you need
to direct head-related ticket notifications to cvs-ghc (perhaps the
latter is preferable?).
it would be nice to have a well-specified workflow (i noticed
that emails to cvs-ghc tend to get lost unless i cc someone likely
be responsible for or interested in the issue, but i don't know
whether i always cc the right person, or whether those ccs are
annoying people). also, the 'darcs record/send -o file/unrecord'
method might be suggested, if it reduces darcs issues? then
there's the question of making small patches that do one thing
only vs conflicts (as in this case, where three separate patches
operate on one file). so a how-to-patch page might be useful.
but just dumping things into trac isn't going to help (too much
in there already, and it doesn't matter if things go old in an
inbox or in trac). you'd need to specify the workflow (what to
do when, whom to cc, which stages does a head patch ticket
go through, how long is it supposed to be in which stages),
preferably without making things so complicated that noone
bothers anymore (you keep adding requirements when i send
patches;-), and preferably with some time estimates so that
patches are still applicable when people get round to them!-)
let's see (rough first draft):
- all non-trivial patches should have feature requests
- ghc hq will assign a cc to each feature request (such as
spj for types, sm for ghci, ian for build system, etc)
- everyone can comment (extra cc's can indicate demand)
- is it ok to implement feature requests that have no
feedback/demand? in my experience, discussion may
not even start unless there's a draft implementation.
- decide whether the feature is suited for inclusion in ghc
- source and test patches should be attached to feature
requests
- ghc hq's cc will review patches and comment
- decide whether patch is accepted or rejected
- apply accepted patches to head and queue for merge
to nearest stable version
so the trac ticket should have a status field somewhat
like: new request / mentor assigned / (un)suited for
implementation / has patch / (passes|fails) tests /
accepted (for head only|for head and stable) /
applied to head / merged to stable / closed.
probably, there should be out-of-sequence stages
"help/answer needed", if the implementer runs into
issues, and "needs clarification", if there are questions
to the proposer/implementer. perhaps these two flags
should be separate from the main status field.
once a ticket reaches the "passes tests" stage, it should
be decided without further delays (how about: within
a week?). it is tempting to specify a minimum discussion
time (at least a week from creation to close?), but that
might go against smallish patches?
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
