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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
