GSOC 2015/Student Application gnarula

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

Contact Information

• Email Address: gnarula94 AT gmail DOT com
• Blog URL: http://gnarula.com <under development>
• 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. The project allows users to deploy Eden on single as well as clustered EC2 instances.

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.

Motivation behind the Project

• 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 (such as the need to compare patches between distributions, track bugs fixed by patches) 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.

Project Details

• 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.

• I plan to build on the prototype I developed for the project (see below). During the first few weeks, I intend to improve the implementation and come up with a design that allows accomodating more distributions (currently the prototype supports only Fedora).

• Existing Fedora Infrastructural Tools can be used in conjunction with the patch tracker. The next part of the project would integrate support for some of these tools.

• Finally, I intend to add support for Debian and Ubuntu packages so that users can compare the patches these distributions apply

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.

The prototype exposes an API to create and list specific packages. Adding a new package results in the following things done behind the scene using Redis Queue:

• The package's git repository is cloned in a working directory
• Major branches are traversed through for patch files. The shasum of the patch files is stored in the database along with the metadata (diffstat and patch comments). Storing the shasum ensures the database contains information about unique patches only.
• Once completed, the job status is changed to DONE and the user may now retrieve the information using the API.

The above design can be expanded to accommodate other distributions in future to allow comparison between the patches.

Further, the metadata can be parsed to gather more information such as the package version and the bugs that the patch addresses.

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-7: Integrate with some of the existing Fedora Infrastructure tools.

• Week 8: Provide a way to resolve package naming differences between distributions

• Weeks 9-10: Add support for Debian and Ubuntu

• Weeks 11-12: Clean up code, add test cases and documentation for the new features. Prepare for final evaluation

College Reopens during last week of July