Well, I think we need one and only one email address for bugs because we'll pass that around all over the place, and it'll reach a point where we can't guarantee the address is always mangled. Instead, I think we're better off having it on a mail server with good spam protection and very little false positives, if any. A false positive on a bug report may not be disaster, but it's definitely not good. But this is an email address that'll be included in packages (which can't be mangled properly every time), distribution packages (Mandriva and Ubuntu make their own...), listed on freshmeat and other software aggregates, etc. So can somebody answer the question,
does gmail allow pop access? Faililng that, does it allow some sort of web service access that we can use?
Yes, we'd have to adopt the xml-rpc. Ummm, I have an ulterior motive for being interested in this in particular. To my knowledge, no open source tracker has good xml-rpc *and* other good stuff. Trac's was still planned last time I checked. My stupid text editor has a broke-ass embedded tracker that I'd like to a) fix and b) offer other integration techniques, so it can support everything I do with it. So I'm willing to personally adopt the xml-rpc stuff (which is what makes my previous experience with it somewhat relevant, I just need to learn internals of flyspray or whatever tracker to do it). I'm not willing to adopt it for trac because I've looked at code for both and I'd rather not even try to hack on trac. But for us,
we would need to adopt it so we can be sure it works for us all the time, or that somebody will fix it even if I don't have time or whatever.
After that, which will hopefully happen pretty quickly, to make the buildbot handle it we need a notifier in the buildbot and a program that takes the notifications and updates the tracker. This can take many forms, but the best is for it to get its own complete svn log for the revision and scan since its last time (the first time it would have to scan for all time, obviously) looking for the string match, and if the buildbot said it built correctly with some conditionals, it'll close the bug. Otherwise, it should post a comment with a link to the build information. Or whatever we want it to do.
Then we get somewhat off tracker discussion.
Armabot needs a buildbot plugin for build updates, and for querying the tracker. It might also get a program for querying documentation, there's a guy in #qt who maintains a supybot plugin that does exactly that. I asked him for the source, I'll probably need to nag him a bit for it. So what I'll get out of doing the builbot-tracker integration is two plugins, one that adds tracker integration to supybot and one that adds buildbot integration to supybot.
Yeah, if you want to host the tracker, knock yourself out.
We can flip a coin, or you can just do it. Now, if you can figure out how to get some of these other guys around here to go test it and tell us what they think, that would really rock.
Anyway, one of the things I did worked to fix it, or it fixed itself magically. Couldn't tell you what, though.
. Maybe I should just adopt one or the other.