KamranKhan
Size: 9317
Comment:
|
Size: 9417
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 112: | Line 112: |
* [[http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/annotate/head%3A/AUTHORS|Arsenal]] |
KamranKhan
Contact information
Your Name: Kamran Riaz Khan
- Email Address: krkhan [at] inspirated [dot] com
- IRC nickname: krkhan
Launchpad ID: ~inspirated
- Skype username: ikrkhan
Webpage/blog: inspirated.com
College-University: National University of Computer & Emerging Sciences, Pakistan
- Major: Electrical Engineering
Project
Project Name
Bug Triaging Improvements for Launchpad/Arsenal
Project Description
The features mentioned below were originally part of the Arsenal bug auto-triaging tools proposal. However, a useful implementation of some of these features requires modifications in the Launchpad API. Similarly, some of the features retain their usability in the web-interface as well. For these reasons, the title of this proposal was changed to reflect the fact that the will not just be limited to Arsenal.
Miscellaneous Arsenal Imrpovements
- Reimplement Perl scripts in Python in order to keep things consistent and reduce the dependencies
Use OptionParser in the Python scripts to support short and long options
Attachment Search
Currently, there is no easy way of searching through a project's bug attachments because of the following reasons:
The REST API does not expose a bug collection for a project.
For a particular bug, an Arsenal search through the attachments requires downloading each attachment locally and then searching through it.
The solution would be to:
Create bug collection attribute for projects, e.g.:
Create bug_attachment collection search methods for bugs, e.g.:
- Create a command-line attachment grepper.
- Create a graphical helper for searching using pygtkmozembed.
Automatic Upstreamer
Add the functionality to forward a bug along with attachments to a remote tracker. General summary of the approach:
Collect bug information in an ArsenalBug instance.
Use Bugzilla::Webservice::Bug over the XML-RPC interface to create a remote bug and upload attachments.
For Bugzilla versions earlier 3.0, use urllib's POST functionality instead of XML-RPC.
Bug Matchmaker
For a given bug, add the functionality to search a remote tracker. However, depending solely on a web-service API or parsing HTML pages will again bring in the issue of 'one trip for each item' for the search. Therefore:
- Launchpad plugins for trackers (e.g., Bugzilla plugin) will be used to help with the searches remotely.
If the user has opted to search for private bugs, use authentication procedures.
Automatic Patcher
For a given bug, generate an automatically patched package from an attachment. The procedure would be to:
- Download the Deb/Tar package
For Deb, unpack and use the dpatch rules to generate a patched version
- For Tar, unpack and patch the source code.
- Report any errors which have occurred during the process.
The functionality will be built directly in Arsenal.
If you would be willing and able to do other projects instead, which ones?
I shall be focusing only on these improvements. They will require lot of polish and testing to reach a level of productivity where compatibility issues among the API's will not hinder the bug triaging process. Therefore, I will not be spending time on other projects during the summer.
Why did you like this idea?
Because:
- I love Python.
- I like playing with web service API's to create interesting interoperating applications.
Please describe a tentative project architecture or an approach to it
- Launchpad core shall be modified to include functionality for bug attachment searching.
- Launchpad web interface and the Bugzilla plugin shall be modified to expose attachment searching, automatic upstreaming and matchmaking.
Launchpad's REST API and launchpadlib shall be modified to expose attachment searching.
- Arsenal shall be modified to include the ability of searching for attachments and automatically creating patched packages.
Give us details about the milestones for this project
- Before June: Get up to speed with Launchpad core development process, bond with the community.
- First week of June: Implement the items mentioned in 'Miscellaneous Arsenal Improvements'.
- Second week of June: Implement attachment searching.
- End of June: Update Arsenal to use attachment searching.
- First week of July: Implement automatic upstreaming.
- Second week of July: Implement matchmaking.
- Third week of July: Modify Arsenal to generate automatically patches packages.
- End of July: Test the changes extensively, merge into main branches.
Why will your proposal benefit Ubuntu?
- It will help ordinary users easily report back more bug information to Launchpad.
- It will increase the cohesion among different project's bug tracking processes. Considerable time is currently wasted because of lack of interoperability among upstream trackers and Launchpad.
- It will greatly speed up the bug triaging process for maintainers and developers.
Open Source
Please describe any previous Open Source development experience
- Worked on following open-source projects:
- Wrote the following applications:
Worked on fixing bugs in various open-source projects
Wrote various articles related to programming
Why are you interested in Open Source?
Because trusting closed source is akin to having an unpublished and unreviewed block cipher as the AES.
Availability
How long will the project take? When can you begin?
The project should take around two months for releasing the features in a production-ready state. I can begin after May 19, i.e., after my current semester ends.
How much time do you expect to dedicate to this project? (weekly)
Around 7-8 hours per day for 4-5 days each week.
Where will you based during the summer?
Islamabad, Pakistan.
Do you have any commitments for the summer? (holidays/work/summer courses)
I have 37 movies — and 2 seasons of Flying Circus pending — on my wishlist, that's about it.
Please designate a back up student (in case you need to withdraw your application)
I don't personally know anyone interested in Launchpad development so any designation would be a random guess at best.
Other
Have you ever participated in a previous GSoC? (describe your project)
No.
Have you applied for any other 2010 Summer of Code projects? If yes, which ones?
Going to apply for the LSB project of cross-distribution dependency translation tool.
Why did you apply for the Google Summer of Code ?
- Getting paid for working on something I love is too good an idea to pass.
- In my country there aren't (m)any opportunities for paid open-source work. So I'd prefer spending the summer in my room working on Launchpad instead of at a company working with crippled Java written by someone else.
Why did you choose Ubuntu as a mentoring organisation?
Because I have worked with Launchpad before and I use it for managing all of my tiny open-source utilities. My project is essentially concerned with Launchpad and Ubuntu is the organization associated with it.
Why do you want to participate and why should Ubuntu choose you?
I want to participate in order to have some productive fun during the summers and contribute to the open-source world. Ubuntu should choose me because I have a great deal of enthusiasm for working on Launchpad with some open-source experience already at my hands. I have a fair amount of experience with Python, GTK+, C/C++, PHP and x86 in particular; and POSIX, open-source and web development in general.
GSoC/2010/KamranKhan (last edited 2010-04-09 17:33:52 by mbl-65-148-129)