[GRASS-dev] trac management - was ticket #110

[Hamish]

Markus:
> > > For me threading works. The headers contain the relevant tags:
Glynn:
> > All responses are treated as replies to the original report, rather
> > than as a reply to a specific message
Markus:
> OK, the same need to check trac modifications for a solution.


note that within Trac you can reply to individual posts, with jump
buttons in the top right corner of the message, so the information exists
within the Trac system. The challenge would be to enhance the trac mail
forwarding code to include those cues.


Keeping a full history of relevant info in the bug log itself is very
important, e.g. for going back to read the history of a long outstanding
bug in the old RT system, where mailing lists discussion is now long
forgotten and links to post #1234567 in the baylor.edu|itc.it|whatever
pipermail archives no longer work, and subject/date for the post was not
given.

It's a bit annoying (not to mention abusive) to have to have to manually
cut and paste someone else's useful m.l. answer into the trac system when
they could have done it themselves. you can always compose & mail your
answer in the email client and cut & paste that to trac; I don't much
like composing in web forms either. it's a similar issue to cross-posting
a question to multiple mailing lists and then have everyone else trying
to understand half a thread. Another way to think of it is the cost of
pasting it into the bug ticket is less than answering the exact same
question a second time a few months later. Which is a similar thing to
answering a ml question in a Wiki FAQ page then just posting the URL to
that in your ml reply.


I suppose it would be nice to recreate the functionality of the old RT
system, where a post from the ml server (From: grass-dev@, Subj: [Trac
#xyz], Originating IP: x.y.z.0 etc spam-proofing) would automatically end
up in the bug's log. But as we all know spam-proofing that is a lot of
work and never 100% successful. But RT did it, and so maybe Trac can be
set up to do it too. If we want that, I think it is up to us to research
and present a solution, rather than expect someone else to do that for
us.
In concept I wouldn't mind devoting some of our devel time to improving
trac if needed, to selfishly "give something back".



Hamish


ps- very good job on the seamless MediaWiki migration / upgrade guys.
only hiccup I found when updating URLs was a directory structure change
for deep-linked wiki JPEGs & PNGs; easily fixed (simplified).


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com