From Fedora Project Wiki

< GSOC 2012

Revision as of 18:41, 10 April 2012 by Bckurera (talk | contribs) (category added)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Contact Information
Name Kamran Riaz Khan
Email Address

Telephone +92 321 504 9479
Blog URL

Freenode IRC Nick: krkhan
Why do you want to work with the Fedora Project?

I have been using Red Hat/Fedora for about 10 years now and would love the opportunity to give something back to the community. I applied for Fedora in GSoC 2007 but could not get accepted. Later on I worked with Ubuntu in GSoC 2010 and in 2011 I got accepted as a duplicate student with Fedora but ended up working on the Tor project. This year I'm applying for Fedora again because I'd love working on the distribution that I have used everyday for almost a decade.

Do you have any past involvement with the Fedora project or another open source project as a contributor? Did you participate with the past GSoC programs, if so which years, which organizations?

(Most of my coding work is available at

  • Google Summer of Code 2010:
    • Successfully completed the Ubuntu project: "Bug Triaging Improvements for Launchpad/Arsenal".
    • Implemented the following features for Launchpad:
      • Attachment Search (Text searches for attachments in bugs of a particular project).
      • Automatic Upstreamer (Forward bugs to remote trackers).
      • Bug Matchmaking (Search remote trackers for entries similar to a given bug).
      • Automatic Patcher (Generate Debian packages automatically patched using attachments of a bug).
    • Technologies used: Python, OAuth, REST, XML-RPC, Web scraping, Debian patch systems, Zope interfaces
      Links: Code Summary, Blog Archive
  • Google Summer of Code 2011:
    • Successfully completed the Electronic Frontier Foundation project: "GTK+ Frontend and Client Mode Improvements for arm (monitor for Tor relays)".
    • Implemented the following features for Launchpad:
      • CLI drop-down menus.
      • GUI bandwidth graphs and logs.
      • GUI connection and general stats for Tor circuits.
      • GUI configuration panel for Tor relays.
      • CLI and GUI exit node selector for Tor circuits.
    • Technologies used: Python, Tor, GTK+, curses
      Links: Code Summary, Blog Archive
  • Open Source Development:
    • Facebook Friends Graph: An application for creating a connected graph of the user’s Facebook contacts for highlighting interesting patterns created by mutual friends.
      Technologies used: Python, GTK+, Graphviz, POSIX threads
      Links: Launchpad Project Page, Blog Archive
    • Bookmark Undertaker: An application which imports Firefox’s bookmarks, updates their status and exports them back to a compatible HTML file.
      Technologies used: Python, GTK+, POSIX threads
      Links: Launchpad Project Page, Blog Archive
    • Pidgin Countdown: A plugin for the popular IM client which allows status messages to "countdown" towards/after a specific point in time.
      Technologies used: C, GTK+
      Links: Launchpad Project Page, Blog Archive
    • GSmolt: A GTK+ frontend for Smolt hardware profiler.
      Technologies used: Python, GTK+
      Links: GitHub Project Page, Blog Archive
    • Pidgin Countdown: A plugin for the popular IM client which allows status messages to "countdown" towards/after a specific point in time.
      Technologies used: C, GTK+
      Links: Launchpad Project Page, Blog Archive
    • slicehosts: A tool to extract host-based traffic out of pcap traces in a speed-efficient manner.
      Technologies used: C, libpcap, GLib
      Links: GitHub Project Page, Blog Archive
    • Inbox Stats: A set of PyS60 scripts written to generate graphical statistics for Symbian mobile phones’ received text messages.
      Technologies used: PyS60, Symbian threads
      Links: Blog Archive
    • CSV Auto-Responder: An application for Symbian phones which scans incoming SMS messages for queries and then replies back with results of data look-up from a CSV file.
      Technologies used: PyS60, Symbian threads
      Links: Blog Archive
    • Emu8086 Hardware Interrupt Editor & Generator: A set of utilities for manipulating the Interrupt Vector Table of Emu8086 and generating hardware interrupts while the emulator is running.
      Technologies used: Python, GTK+
      Links: Blog Archive
    • Worked on fixing bugs in various open-source projects.
    • Wrote various articles related to programming.
  • Miscellaneous:
    • Progressed through the qualification round for Google Code Jam 2008.
    • Designed an XHTML compliant, resolution and browser independent website for my blog.
Will you continue contributing/supporting the Fedora project after the GSoC 2012 program, if yes, which team(s), you are interested with?

After my graduation in this summer I shall have more spare time to contribute to open-source projects and I plan on supporting the Fedora project by working with the infrastucture team for tools such as the one proposed in this application.

Why should we choose you over other applicants?

Apart from having open source experience in a variety of forms such as programming, scripting, web development, packaging, community discussions over mailing lists/IRC, bug-fixing and blogging etc., I am a resourceful and self-motivated person when it comes to any technical issue. I learned everything about programming and Linux on my own while having little guidance on FLOSS culture (I grew up in Saudi Arabia and few people there knew about existence of Tux). Bryce Harrington, the mentor for my first GSoC summed up the summer collaboration in following words:

Congratulations and thanks again for all your work this summer, you did an exemplary job completing everything you set out to do and it was a pleasure working with you – in fact I learned several new python tricks myself from studying your code! I look forward especially to putting the new bug upstreaming code into practice once I’m back working full time on Ubuntu.

I’m glad to hear you had a good experience and hope it was able to give you a good foundation for working in open source in the future.

Comment by Bryce Harrington — September 16, 2010 @ 9:18 am

Proposal Description
An overview of your proposal

To create a UI frontend for fedora-easy-karma, with support for (at least) the following features:

  • List installed/available packages for testing
  • List bugs related to an update package
  • Show dependency tree
  • List test cases
  • Fetch related Bodhi comments and karma points
The need you believe it fulfills

The project makes it easier for end-users to participate in the process of updates-testing by eliminating the CLI-learning curve of fedora-easy-karma.

Any relevant experience you have

I have worked with Python, XML-RPC/REST APIs and PyGTK as explained in the [#experience experience] section.

How you intend to implement your proposal

I plan on using PyGObject/GtkBuilder for creating the UI and have created a mockup which can be found at the gfedorakarma GitHub repository. A screenshort of the UI is given below:


For implementing the features I have listed here's a list of general high-level directions I intend to pursue:

  • Yum for listing packages/depenencies: Use the yum.YumBase Python module for communicating with the RPM database.
  • Bugzilla for listing related bugs: Use XML-RPC to communicate with Redhat's Bugzilla.
  • Bodhi for pushing/pulling karma information: Use fedora.client.BodhiClient Python module for communicating with the Bodhi server.The UI shall allow the user to choose whether to list only the packages that are installed on the current system. Python's unittest module shall be used to ensure sanity of the specified API's via test cases.
A rough timeline for your progress
  • April 23-May 21 Community Bonding Period: Familiarize myself with yum and Bodhi APIs. Discuss ideas with the Fedora community.
  • May 21-June 3 (Week 1-2): Implement package listings along with treeview functionality to dynamically update models as queries are typed.
  • June 4-June 17 (Week 3-4): Implement related bugs information.
  • June 18-July 1 (Week 5-6): Implement dependency trees.
  • July 2-July 13 (Week 7-8): Prepare code for midterm evaluation by reviewing the progress with tflink.
  • July 13 (Mid-term evaluation): Submit code for mid-term evaluation.
  • July 16-July 29 (Weeks 9-11): Implement fetching/updating of Bodhi comments and karma points.
  • July 30-August 12 (Week 12, Suggested 'pencils down' date): Internationalize the UI and release to the community. Comment the code thoroughly, write user documentation and review the project state.
  • August 13-August 20 (Week 13, Firm 'pencils down' date): Polish the code and documentation and fill up final evaluations.
Any other details you feel we should consider

The first time I tried using Red Hat Linux 7.2, the dial-up didn't work as I was using a soft-modem. The X server didn't work either, and I had absolutely no experience with anything remotely CLI related. So I had to boot into Windows, Google for a solution, reboot into Linux, try that solution and rinse and repeat -- all while trying to evade parents' curfew. It took me about 4 months to get X working. I'm not sure how or why you should consider that but you definitely should!

Have you communicated with a potential mentor? If so, who?

I discussed the proposal with Tim Flink on IRC who gave me the heads up on using PyGObject as long as Glade doesn't crash for me :) . The ideas listed in this proposal were taken from his blog.