Trac & spam🔗
How to fight spam with Trac🔗
There is not built-in mechanism in Trac to fight spam. However, plugins enable to setup several ways to stop spam (or at least, reduce it).
One of them is Akismet, a web service who can tell you if some message is a spam or not. It is able to catch most of the spam. A bayesian filter complement this service. A learning step is mandatory and can become cumbersome when the vast majority of the tickets you receive is just spam. I used these two mechanisms on my Trac instances.
Another path is to require an account to post a ticket. Creating an account each time you want to create a ticket for some software is burdensome. I did not want to do this to the poor souls that have found a bug in one of my projects. An alternative is to setup a public account and adding somewhere in the page some instructions on how to use it when you want to open a ticket but don’t want to open an account.
Despite Akismet and the bayesian filter, I still got two or three spams a day. I catched them in my RSS flow or in my email if they were not classified as spam.
There are two steps to remove the spam:
- tell the bayesian filter by using the administration panel in the web interface,
- remove the spam from the database using some SQLite commands directly on the server hosting the Trac instance.
Indeed, Trac does not propose the possibility to remove a ticket. Of course, there are plugins, but you must find them, install them, find how to configure them, etc.
GitHub is a popular source code hosting service which uses Git as a backend. This is a proprietary platform but a lot of open source projects have migrated to it, thanks to its features and the good performances.
Everybody is on GitHub. This was the ideal opportunity.
UPDATED (2011.05): Peter Pentchev did point me to Gitorious which is a free alternative to GitHub. Its source code is licensed under the AGPL. Unfortunately, I did not consider it because it was lacking an issue tracker.
First, GitHub allows you to host Git repository. You push your Git repositories. There is a nice and fast web interface to browse them. However, I still keep an instance of cgit.
Then, GitHub is very popular because they drive people to fork projects. With one single click, you can fork your favorite project. You get a copy which is synchronised with the forked project.
There is also a wiki (accepting many markup syntaxes). This wiki is also available through Git.
At last, GitHub offers a minimalistic ticket system. You open a ticket, you make some comments, you can add a tag or two and you can close it. That’s all. Quite light. But enough for small projects like mine.
However, there is more! Do not open a ticket to send a patch. There is no way to attach files to tickets. You need to fork the project, create a branch with your patch and request a “pull” for your branch. This will appear as a ticket but your commits will be linked to it. The author can then review and comment your branch, ask for some changes and if they want to integrate it, a simple merge is sufficient. They can even do it using the web interface. Convenient.
Socially, you can comment commits, tickets, projects and subscribe to a lot of events. You can receive and answers tickets by mail.
However, an accound is mandatory to open a ticket. Since there is a lot of projects on GitHub, this account should be useful for a lot of software.
To cut a long story short, even if GitHub is a proprietary platform, it offers nice and interesting features. More and more projects migrate from Google Code to GitHub even if there is less features on the latter.
I have searched for tools to migrate automatically tickets from Trac to GitHub. For example, there is SD.
At last, I have done it manually. GitHub API is well documented and there exists bindings in various languages including Python but it is a very limited API. You can’t choose the number of the ticket nor its date.
I have also rewritten
README files to use the markdown markup and
avoid the use of wiki pages when possible.
I have also put some URL redirections with the help of nginx.
In conclusion, even if maintaining Trac instances was not a lot of work, one thing that I do not have to do anymore. And no spam on GitHub, I assume.