On 03/03/2010 02:46 PM, Peter John Hartman wrote: > I agree about the issue trackers + the mail integration. A small > suggestion: none of the issue/bug tracking systems do collaboration very > well either. What I mean by "collaboration" is the capacity to pass a > single document back and forth with several "notes" appended to it. a > giant
You might think on a distributed bug-tracking system similar to a list of bug-reports inside a git system with the possibility to create new bugreports "on the fly" when the mail-server receives a specific mail (you somehow have to define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). There should be a 'central' (though not required) bug-tracking server for all those coming with bugs on you project-website. there, the current bug list and state is a available and an interface to add new bugs. then you could place some sort of hooks into your bugtracker (bt) configuration: bt/.config/new -> send mail to mail-adress with new bug then you can manage bug-notification via mailing lists. For users that don't want to use the website, you could listen on mails in a specific form/with a specific header to pass it directly to bt parsing it. if the parsing fails, automagically send a mail back to the composer with annotation where it failed, if successfull, send back a success-mail. usage could be like (in a distributed way): $ cd bugs/projectname bugs/projectname $ bt pull # pulls all new bugreports from server 7 new bugreports bugs/projectname $ 51 unresolved bugs 123 pending bugs where 'pending' means that their state is in "needs check if the bugfix works or not, waiting for approval" or something like that. If you want to make comments to a file, make them and afterwards a bugs/projectname $ bt commit -m "some annotation" bugs/projectname $ bt send # send new file to whole mailinglist bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a specific user would do the rest. something like that. Didn't think too carefully on it.
