There is a contrib script to take email as input to creating new Trac tickets. http://trac.edgewall.org/browser/trunk/contrib/emailfilter.py?rev=latest
Would be quiet useful for things like webmaster or release engineering. Could lead to some spam, not entirely sure how to handle that.
I'm putting this under "should we?" for now. in general I'm find with just using the web interface. So far on smolt and Fedora-Infrastructure our noise ratio has been perfect.
Ahh, it just dawned on me you're talking about hosted as a project, not Fedora-Infrastructure. I'm down with getting it set up but keep that spam out of the F-I project :)
Another possibility is located here: https://subtrac.sara.nl/oss/email2trac/wiki
This probably provide us with a better setup then the original one.
What do you think Jesse ?
After playing around, you're right, the email2trac is a better choice for us. It is more robust, allows updating tickets via email as well, and it is going to be easier to use it with multiple projects.
Here's where I'm at right now. I've compiled email2trac and tossed it in my homedir on hosted1. I am able to make it use a local config file and I've catted a raw email message through the python script and was able to get tickets to show up in one of my projects.
Each project will need a config entry in the config file (it's not smart enough to take a base path and add the --project argument to said base path, yet. I can likely make that modification shortly).
The next step would be to make a package out of this code, and get it into EPEL so that we can install it on hosted1, and then get the config file managed in puppet.
Trac projects that wish to have this service will have to enable anonymous ticket creation and modification so that the emails can create and update the tickets. They'll also have to request that we create an alias for them on hosted1 to call the email2trac.py script with --project=<project>
The last little hurdle is getting the script setup in such a way that it can be executed by postfix and also have write access to the Trac databases. I'm going to need a little bit of help with that.
Over all, good progress though, we're very close to letting this rip!
Review ticket is https://bugzilla.redhat.com/show_bug.cgi?id=447338
EPEL 5 build is http://buildsys.fedoraproject.org/build-status/job.psp?uid=39058
I installed email2trac on hosted1 and setup a few config files to test this.
/etc/email2trac.conf comes from the package and needs some extra editing to set our site defaults as well as add sections for each project that would like to get tickets from email.
/etc/email2trac/aliases is a directory/file I created that will maintain the aliases used to deliver mail. It appears that we'll have to do an alias for each project, so that we can call email2trac with the proper arguments. In the future it could be possible to just send every mail to a given alias to a program which will use the to: field as an argument to figure out which project gets the ticket, as well has have email2trac make use of a 'basedir' for trac projects and again take the project name as a final argument to the trac space, thus negating the needs for a configuration stanza + alias for each project.
I'm now moving these items into puppet, after discussion as to what domain / alias schema we want to use.
I should note, /etc/email2trac/ has to be writable by apache, and /etc/email2trac/aliases has to be owned by apache. This will let postfix know to run /usr/bin/email2trac as the apache user which has write access to the trac project databases.
puppet configs now in place. Decided to go with <project>@fedorahosted.org as the email alias template.
Next up is creating a SOP for adding projects to this service. Once that's done I'll close this ticket.
http://fedoraproject.org/wiki/Infrastructure/SOP/HostedEmail2Trac has been created. Closing the ticket.
to comment on this ticket.