It would be nice of the current versions could be supported in addition to branches. Or rather, branches in addition to current versions. I think that's more of an organizational caveat than anything else, having custom field support (which is planned for the 1.0 release) would take care of that. So we basically need to have current versions "trunk" and whatever branches we have, in this case "0.2.8", with 0.2.8.3 being a future version that we'll turn into a present version when it's released (obviously).
I like the difference between future/present versions, though. It makes it possible to really track future versions. I don't remember whether or not trac had a mechanism for it, and since I haven't posted my Mantis rant (it's not that bad, mostly it's about usability because I didn't go deep enough to see anything else).
The bugs-affecting-version-X mechanism looks good, the only problem is when a bug affects multiple versions. I.e. 0.2.8 branch can have it, trunk can have it, and 0.3.0 can have it. What you pulled up is what I declared previously was support until I noticed it can only be marked with one version affected. It should be multiple versions (same way you can have multiple assignees), and multiple future versions as well. A bug that affects the trunk right now will be fixed in 0.3.1, ideally, and if the same bug is in 0.2.8 branch, then it's also planned to be fixed for 0.2.8.3. Also, if the bug is in 0.3.0 and the trunk, then when it's closed we'd like to be able to see that it still affects 0.3.0 and where it was fixed. I won't say waht's there is worthless, it might just get us to the 1.0 flyspray release when the guy in the irc channel says it'll do what I've described here.
Anonymous reports was already in the requirements.
Email reporting as an addendum to it wasn't. I'm willing to hack in an xml-rpc layer, then we need a fairly simple python bot to use it. There is code laying around for such a thing, and if we're willing to maintain the xml-rpc for flyspray, they're willing to take it. The reason they don't have it now is because the guy who wrote it left and nobody's offered to maintain it. I'd rather do it as soap, though, because soap is waaay more expressive. Xml-rpc is basically "execute this function, and you can return either a scalar or an array, and that's it". SOAP gives you more complex data structures that can be transmitted by letting you define them yourself. Anyway, soap or xml-rpc is beside the point. So with that we can have both buildbot integration and the email dealie, but I can tell you right now we're going to want to make sure the mail server has adequate spam protection. On the freeciv-dev list they're having trouble with their RT installation getting too much spam. I heard somewhere that Gmail gives you pop access? is that correct? And spam protectors for pop access?
Similarly, armabot could use the xml-rpc layer to close bugs automatically when the commit message says it. The only problem there is that armabot doesn't get the full commit message. I still think the buildbot is the best place to do that, where the build can be tested first, giving us some automated QA on bug closing. If the developer wants to contest the buildbot, he can always go close it by hand, which is what he has to do anyway if the buildbot isn't doing it. The catch here is that the buildbot doesn't get all commit messages until a commit triggers a build, until then it only does "svn info" to find out when the last commit was, so the timing of the closing of bugs would be dependent on the buildbot, which is fine for me.
Anyway, I'd like to know what other people think. I've been careful not to put language in requirements because deep down inside I only really care about how easy it is to setup (I've just assumed I'm going to host it since I'm already the tracker admin on sourceforge, but I don't have to host it). But the fact that it's in php rather than python is a big plus, imo. Python's a wonderful language and y'all know how much I love it, but I still think php is a better language for a web application, even if I hate it. And with as many people around here that already know php compared to python, that's a good thing should we find ourselves having to nurse the tracker, which gives good contingency options.
