GSOC 2016/Student Application fhackdroid

Pagure Contact Information

Name: Farhaan Bukhsh

Email Address: farhaan.bukhsh@gmail.com

Blog Url : https://farhaanbukhsh.wordpress.com

Freenode IRC Nick: fhackdroid

GitHub: https://github.com/farhaanbukhsh

Pagure: https://pagure.io/user/farhaan

Social Media Accounts

Twitter: https://twitter.com/fhackdroid

Why do you want to work with the Fedora Project?

I have been using Fedora for a long time. When I started contributing to fedora-infra during August 2015 when Kushal introduced me to #fedora-apps in #dgplug, I actually found it really welcoming. I felt a sense of belongingness, I started contributing to different project and all the people that were in fedora-apps channel started mentoring me. It was the helpful and amicable nature of the community that inspired me to work with them and in no time even I started helping people.

Fedora community has taught me that community comes before code and this is one of the many reasons I want to work with Fedora Project.

Past involvement with Fedora Project:

Nuancier 1 commit
pkgdb2 2 commits
Bodhi 7 commits
Pagure 54 commits 
Fedora Autocloud 3 commits

Past involvement with other Open Source projects:

Mozilla

I volunteer for an organization, FSMK which stands for Free Software Movement Karnataka, which works towards spreading Free Software ideology.

I have been attending training at #dgplug which actually guides you to become a contributor

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

Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with?

Yes, I am planning to continue contributing to Fedora-Projects after GSoC, I have previously been contributing to Fedora-infra and I like the experience. I am really interested to continue working on Pagure, because there are a lot of features that needs to be written and it is quite challenging to work on it.

Why should we choose you over the other applicants?

I have been contributing to Pagure since September 2015 . I am very familiar with the code base, I think I have touched most of the files in the code base at least once. I have a lot of experience in developing features for Pagure, there are 54 commits authored by me in Pagure which includes various bug fixes as well as different features. I am a very enthusiastic person when it comes to solving an interesting problem which is very much required.

I am very comfortable with the community, and my experience with the people and the code base is what makes me different from the other applicants. I want to carry on contributing to Pagure even after GSoC because I want to make Pagure the best code reviewing system available.

One major advantage that I have over others is my familiarity with Pagure’s Development Lifecycle.

Proposal Description Overview and The Need

The suggested ideas for Pagure were listed below, I am keen on implementing these because these features will be really helpful and will add more value to the project.

Code Search Private Repository Checkout Pull Request locally Static pages for Repository Jenkins Hook

Code Search

There is no way to search code in Pagure, with this feature I am trying to provide a way in which user can search code in a repository. This is one of the primary goals .

Jenkins Hook

It is a feature which will be used for continuous testing of code for Pagure. Every time a commit is pushed on master branch, the code is tested and the result of the Jenkins build is attached to the pull request. This is a secondary goal.

Private Repository

Pagure doesn't have a way of making a repository private , but it has the ability to achieve it. Private repository is the one in which the code is not visible to the non authorized user, the owner can add committers to the list. This is one of the primary goals.

Checkout Pull Request Locally

This can be used to check a pull request locally, with this feature user can locally fetch a pull request, it creates a different branch in the local repository to test a specific pull request. This is a secondary goal .

Static Pages The idea is to give a static page to the projects hosted on Pagure. So that each project can have a page where introduction of the project and various other details can be mentioned. Pagure already has docs.pagure.org which can be changed to project_name.pagure.org for clean and organized look. This is a primary goal.

Any relevant experience you have

I have worked on Pagure, so I am quite familiar with the code base, I have been fixing bugs in Pagure and have been a user of Pagure too. I have written few features for Pagure like, editing user comment on pull-request and issues. I have also written features to create user and change password for local auth in Pagure. While writing the change password feature I helped to migrate the encryption strategy from SHA to bcrypt. I also have experience in writing test cases for Pagure.

How do you intend to implement your proposal?

Code Search

First approach was to try git grep, but it is really slow and might affect performance of Pagure, the second approach that I want to try is indexation which will improve the performance and help to get searched result faster. There are various other approaches that we may need to look into, pyLucene and Whoosh are two libraries that can be used for indexation which leads to improved performance, a lot of experiment needs to be carried on to find the best way to do this.

Jenkins Hook

For implementation of Jenkins hook, the major problem that is faced is with relating the build to the specific pull request. For solving this problem we are trying to have an external service running whenever a pull request is accepted that is informed to the service, the service in return triggers the build and monitors it , when Jenkins build is completed, the service polls Jenkins periodically and returns the status of that build to that specific pull request, now this can be used to attach notification to the Pull Request. I am looking into how to design the services and have communication between Jenkins and Pagure. Async Programming is the way we can achieve writing that service. The diagram for implementation:

Private Repository

Repository should have a switch to make it public or private, the self-service strategy is the one I will try to implement. Using this user can restrict access to a particular repository. For implementation, conditions has to be checked, the repository and user relationship should be looked into. Which user should be able to access the repository and which user shouldn’t be able to. Public cloning has to be turned off.

Checkout Pull Request locally

I have been reading about it and it seems pretty achievable with this github article. We need to implement url for Pull Request like ref/pull and using that ref as ID we can fetch the Pull Request locally. The pull request can automatically be fetched as mentioned in stackoverflow question. This basically points out that every pull request should be given an unique ref/ID using which it can be fetched locally , doing that will create a new branch where the Pull Request can be tested.

Static Pages

We can use the doc hosting setup for this issue. Instead of having a url like docs.pagure.org, we can give static page hosting to each repository on their request with url like, project_name.pagure.org. This can also serve the purpose of hosting the docs on this static page instead of the landing page of the doc.

23 May - 4 June : Implementing private repository hosting.

4 June - 11 June : Jenkins hook, where the first two days, I will work on reading about the server and then a way to individually identify which build belongs to which Pull Request

Mid Term Evaluation Deliverable: Getting Private Repository hosting to work and having a private ticket is the major goal for mid term and Jenkins showing notification to individual Pull Request is the secondary goal for me.

12 June - 10 July: Checking the feasibility of code search, figuring out the best strategy to follow to implement it, whether it is PyLucene or Whoosh or the way indexation is implemented in HyperKitty.

11 July - 15 August: Static pages , replacing docs.pagure.org to project_name.pagure.org

15 August - 30 August: Checkout pull request locally

Final Deliverable:

Final deliverable will include Pagure with the ability to host private repository There will be a Jenkins plugin which can be used to monitor project status i.e does it pass all the tests or not. Pagure will have the ability to host static web pages for each project and users will be able to search code in a given repository. On receiving a Pull Request user will have the ability to check it locally and then merge it. After these goals are achieved and if I will be left with time , I would like to work on issues like making Pagure the frontend of pkg.fp.o , fixing the memory leak where when a very large change is requested Pagure returns a 500 error and other bug fixes.

Any other details you feel we should consider

I might have my university exams that will last for a week or two , since dates are not officially out , the tentative dates are 4 June – 15 June, during which I can work for at least 6 hours a day, after that I don't have any commitments. I will be having vacations during which I can work for 10 hours minimum. My college will be reopening on 1st August but I don't have any major exams and college is quite supporting so I could clock the same number of hours.

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

Yes, I have been in touch with pingou, he has been a constant support and guide for me while contributing to Pagure.