Folks, I am starting to think that Gump3 needs to integrate with JIRA, in preference to building some functionality itself. Basically, Gump3 ought leverage JIRA's notification ability (e-mail and RSS), and it's tracking process (commenting, tracking, status, history). Basically Gump outages (other than software bugs in Gump) ought be treated as JIRA issues like any other.
I like this idea because we are leveraging what exists, rather than re-inventing the wheel, and (in theory) we are putting information where information ought reside. My belief is that if we had a documented record of Gump outages and fixes we'd have accumulate some awesome exchanges. [We've tried doing that on the Gump blog (which died w/ Brutus, I think), but that is gathered from folks memory of exchanges. Much nicer if we could record as we go.] I don't know how good JIRA is for historical queries, looking for hot spots, or trouble areas, but I'd have to assume that is something they'd do better than we. I did a quick look for ways to talk to JIRA, and I see they have a WebServices API (built using AXIS). I've not tried it, but I can't imagine that Python couldn't talk to JIRA quite easily, and with WebServices it ought (hopefully) be able to exchange issue identifiers (etc) when an issue is created. For example, if Gump3 could (upon build failure) check if there exists, for that project, an (open) issue in JIRA, that was create by Gump, then it'd do nothing. If not, it'd create an issue and store the issue identifier for later. Gump could add build outputs as attachments, and so forth. I've not read the WSDL sufficient to know this is all doable, but it looks a rich interface. WSDL: http://jira.atlassian.com/rpc/soap/jirasoapservice-v2?wsdl Some considerations ... 1) Clearly JIRA doesn't cover all the projects we interact with. If we chose to go this route, perhaps we could create a project for Gump-Issues for non-JIRA projects. 2) I don't know how JIRA works across projects, but (say) project A fails to build and a human (or one day code) determines that the root cause was dependent project B. Could a project A JIRA issue be assigned to B, or somehow closed w/ reason being the new B issue? I'd like to be able (over time) to really track the impact of outages/incompatibilities. 3) Security. I don't know what authentication mechanism it uses, or if infra@ would allow this to be enabled. (Unfortunately this isn't enabled on Apache today.) Further, I don't know if connectivity from vmgump (an untrusted location) would be allowed (although SMTP connectivity has been.) Apache JIRA: http://issues.apache.org/jira/rpc/soap/jirasoapservice-v2?wsdl Integration has some downsides, but I wonder if it is the right thing to do for keeping Gump3 simple, for the greater ASF community, and for leveraging others. Thoughts? regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
