Background & contact info
My name is David Wendt. You can contact me...
via Email: email@example.com
via XMPP/Jabber/GoogleTalk: firstname.lastname@example.org
via AIM: ?AnonBound.
- via IRC: dwendt at irc.debian.org
I am a sophmore-year undergraduate Computer Science student at Stony Brook University. I have experience in multiple programming languages, and participated in Google Summer of Code in 2009 for Debian.
The project I am proposing is a "Debbugs Bug Reporting and Manipulation API". The debbugs system allows Debian maintainers to manage existing bug reports and fix problems quickly. However, the primary method of interface with this API is e-mail. There is an existing SOAP API, but it is limited to read-only operation. This proposal would cover extending the existing SOAP API to cover bug submission and report manipulation.
By "bug submission", we refer to the functionality being provided by processing incoming e-mails to email@example.com. And, by "report manipulation", we refer to the functionality being provided by processing incoming e-mails to firstname.lastname@example.org.
The project would involve writing and testing a new API for the two above-mentioned functionalities. New client code could use the SOAP API to interface with the BTS to add functionality. Reportbug is an example of a piece of candidate software which could be modified to use the SOAP API.
The new API will not replace the existing e-mail system.
Benefit to Debian
Implementing this project will allow software to interface directly with debbugs without relying on e-mail. It would not replace or depreciate the e-mail interface, which would remain the primary mode of access for debbugs. Debian would gain the ability to write software that uses debbugs in situations where e-mail is inappropriate. It would also make it easier to write new kinds of software that interface with the BTS.
This is a list of possible use-cases for software that would leverage the new SOAP API.
- Joe is an intermediate-level computer user with enough knowledge to operate a Debian system.
- Joe expieriences an application crash.
- Joe is prompted to fill out a bug report by some other application.
- However, Joe does not have a configured mail system or MTA, or it is misconfigured and cannot send mail to the general public internet. This is common on non-server systems, for various reasons. (Joe isn't capable, Joe doesn't have SMTP mail, Joe is on a network which blocks his SMTP)
- The bug report application instead uses the SOAP API to send the bug report, not bothering the user with the details of the mail system.
- As a consequence, more users are able to submit bug reports without worrying about mail.
- Brian is an application developer for a popular upstream project. He gets a number of bug reports for things that are Debian-specific, and would like an easy way to resubmit those bug reports to Debian.
- Brian writes a small extension to his current bug report system which allows him to send bug reports downstream.
- Brian finds a bug report about not being able to install the relevant software.
- Brian uses his new extention, which leverages the SOAP API to resubmit the bug report to Debian.
- Harold is a Debian developer that wants to implement automatic test case checking.
- Harold writes a piece of software that takes test cases in some format, does the test, and then posts the results as a comment to a bug report.
- Harold points the software to a bug report with a test case linked.
- Harold's software uses the SOAP API to report on the success or failure of the tests.
In the case that API implementation and testing is finished before the GSoC end date, I could additionally alter existing BTS-interfacing software to use the new API. For example, we could add SOAP API support to reportbug so that it can use the SOAP API if the system MTA is broken or misconfigured. This would make it easier to submit bug reports for people who don't use system mail (i.e. people who use webmail).
I do not have major committments or jobs during the GSoC work timeline. I am considering taking a single summer class during the second half of the summer. This would be a class on Tuesdays and Thursdays from 1 to 5, constituting about 8 hours a week. I do not believe it would interfere with my GSoC work, however I think I should mention it.
DebConf and travel arrangements
Unlike last year, I will be able to attend DebConf. I live within commuter rail distance of New York City and my travel expenses would be limited to a peak ten-trip LIRR ticket between Kings Park and Penn Station (see: Zone 10 <Kings Park> to Zone 1 <Penn Station>, about $150) and subway fare between Kings Park and the 118th St. Columbia University station (see: $2.25/ride * 2 rides for round trip * 5 days at debconf = $22.50)