GSOC 2015/Student Application gnarula

• Your name: Gaurav Narula
• FAS Account: gnarula
• Fedora userpage:

Contact Information

• Email Address: gnarula94 AT gmail DOT com
• Blog URL: http://gnarula.com
• Freenode IRC Nick: gnarula

Why do you want to work with the Fedora Project?

While making the switch from Windows to Linux, Fedora was one of the first distributions I tried. The idea of the distribution being free and encouraging modifications and distributions, community support over IRC and Forums were definitely some of the reasons the distribution stood out over the others. I look at this GSoC project to be an opportunity to give back to the distribution which has been a part of my life over so many years and hopefully contribute in the days to come.

Do you have any past involvement with the Fedora project or any other open source project as a contributor?

I began contributing to Open Source Projects during Google Code In 2011. During the competition, I contributed to Limesurvey, VideoLAN and Sahana Software Foundation. Winning the competition [1] further encouraged me to learn more about OSS and contribute to other projects.

Since then, I’ve enjoyed giving back to the Open Source community. I’ve recently developed a keen interest in authoring articles related to web development utilising new technologies. Back in February 2013, I wrote an article on Nettuts about developing a Twitter Clone using Django as a part of the “Developing a Twitter Clone” series [2]. Later in May 2013, I developed a Sublime Text plugin in Python that acted as a wrapper for a CLI tool used by Laravel (a PHP framework). Last March, I wrote an article on making a Multiplayer Version of Connect 4 using Socket.io and Node.js [3]. [1]: http://google-opensource.blogspot.in/2012/02/google-code-in-2011-grand-prize-winners.html [2]: http://code.tutsplus.com/tutorials/building-ribbit-in-django--net-29957 [3]: http://code.tutsplus.com/tutorials/connect-4-with-socketio--cms-19869

Did you participate with the past GSoC programs, if so which years, which organizations?

I went on to participate in Google Summer of Code 2014 and contributed to the Sahana Software Foundation. My project involved providing an interface to deploy Sahana Eden on remote servers using the Eden framework, automating the task behind the scenes using Ansible.

Will you continue contributing/ supporting the Fedora project after the GSoC 2014 program, if yes, which team(s), you are interested with?

Given my recent interest in infrastructure development, automation and release engineering domain, I look forward to contributing in some of those fields.

Why should we choose you over other applicants?

The Patch Tracker project requires experience in Python, Linux and other web related technologies. Over the last few years, I’ve had the opportunity to work with projects requiring extensive use of these technologies. As someone with a passion for learning new things and employing them in my projects, I believe I will be able to come up with a sustainable and maintainable application which would fit the goals of the project in the long run.

Project Details

The idea for the Fedora Patch tracker is largely inspired by the Debian Patch Tracker (https://anonscm.debian.org/cgit/users/seanius/patch-tracker.git/tree/), which provided a way to view patches applied in Debian Packages across different Debian releases. While Fedora does provide a way to view patch details for packages (Example: https://apps.fedoraproject.org/packages/ipython/sources/), there is room for more features and a need for a targeted application for tracking patches.

Learning from the Debian Patch Tracker application, the project aims to develop a web application to track patches across popular linux distributions while focussing the efforts on Fedora. The ability to compare patches across different distributions would come in handy for the package maintainers.

The maintainability of an application largely depends on the underlying frameworks used. I plan to develop the application using Flask to provide the backend API and AngularJS for the frontend logic. Both the frameworks are extensively documented and offer a rich set of features apt for the project. The project also aims to make use of existing fedora infrastructure tools like fedmsg and anitya to watch for commits and act on them.

Moving over to the implementation, the way the patches are stored varies with different distributions. Fedora for instance stores the information in git repositories, Debian and Ubuntu maintain *.diff.gz files with patches in their repositories while openSUSE stores the patches in the Source RPMs. These differences in patch retrieval methods have to be accounted for while building the application in a way that it’s easier to add support for new distributions later on. Differences in package naming across different distributions is also of great concern. However, some user intervention and use of tools like distromatch (http://enricozini.org/2011/debian/distromatch/) or whohas (http://www.philippwesche.org/200811/whohas/intro.html) offers a solution.

Prototype

Over the last few weeks, I’ve developed a prototype for the application which is available at http://sleepy-ravine-5158.herokuapp.com (sources at http://github.com/gnarula/fedora-patch-tracker). The current features allow adding packages and viewing diffstat and patch comments for a given package. The prototype uses Flask for the backend API, Redis Queue (RQ) for background job processing and AngularJS for the frontend logic which is the stack I intend to use in the main project.

The prototype works by queuing “jobs” in the background which are responsible for the grunt work like cloning the git repositories and caching the patch metadata in the database. The frontend polls the application continuously for the status of the job and if successful, displays the list of patches. Clicking on a patch would show its metadata - the diffstat generated by git apply --stat, the commit message and comments and the Fedora releases the patch exists in.

Timeline

Community Bonding Period: Learn more about existing fedora infrastructure tools and the build process

Weeks 1-2: Improve on the prototype and make the backend modular to accommodate more distributions

Weeks 3-5: Work on retrieving patches in Fedora effectively, clean up code, write tests and prepare for mid-term evaluation

Week 6: Integrate with some of the existing Fedora Infrastructure tools.

Weeks 7: Provide a way to resolve package naming differences between distributions

Weeks 8-9: Add support for Debian and Ubuntu

Week 10: Clean up code, add test cases and documentation for the new features

Week 11-12: Add support for openSUSE, prepare for final evaluation.

College Reopens during last week of July