No edit summary |
No edit summary |
||
| Line 45: | Line 45: | ||
2. '''Running unit-tests''': It's important to run unit-tests before launching the product into production in order to minimise failures. | 2. '''Running unit-tests''': It's important to run unit-tests before launching the product into production in order to minimise failures. | ||
3. '''Deployment''': We can plan to deploy the very first version in production of shumgrepper after the above two steps would be completed. | 3. '''Deployment''': We can plan to deploy the very first version in production of shumgrepper after the above two steps would be completed. It will involve the following steps: | ||
* First, I will have to create a rpm package. For that first I will create a .spec file which will contain all the necessary information about the software being packaged. | |||
* Next is to add license to the package and other small steps to make it ready for packaging. Then using rpmlint to check for errors in SPEC files, RPMS, SRPMS. | |||
* Then I will use Mock to check if we had accurately listed build dependencies and Koji to test SRPM to other platforms. | |||
* After all this, I will create a review request on bugzilla. | |||
4. '''Testing and optimisation''': When it comes to compare among different packages, it does so by comparing each file of one package with each and every file of other packages to find out common or different files; the queries take too long to return results. I need to find some ways by which we can plan to optimise these queries. | 4. '''Testing and optimisation''': When it comes to compare among different packages, it does so by comparing each file of one package with each and every file of other packages to find out common or different files; the queries take too long to return results. I need to find some ways by which we can plan to optimise these queries. | ||
| Line 54: | Line 58: | ||
* We can also display the count of total packages having GPL license on /packages page. | * We can also display the count of total packages having GPL license on /packages page. | ||
7. ''' Testing & Documentation''': This will involve testing all the end-points and their results. Also documenting everything implemented so far. | 7. ''' Testing & Documentation''': This will involve testing all the end-points and their results. Also documenting everything implemented so far. | ||
* It will also involve maintaining the package and updating it for further changes. | |||
8. '''Improving the GUI''': We can improve user experiences with the app by making considerable changes in the UI. This could involve: | 8. '''Improving the GUI''': We can improve user experiences with the app by making considerable changes in the UI. This could involve: | ||
* We can have some visualisation (in the form of bar charts) which will give an overview of the changes among different packages. | * We can have some visualisation (in the form of bar charts) which will give an overview of the changes among different packages. | ||
* While comparing among three packages for finding different files among the three. We can provides some stats where we list the count of differences between every two packages. | |||
===Deliverables=== | ===Deliverables=== | ||
Revision as of 18:17, 25 March 2015
Project Title : Shumgrepper
Personal Information
- Name : charul
- Fedora Profile : charul
- GitHub : charulagrl
- Timezone : India, UTC +5:30
Contact Information
- E-mail : charul.agrl@gmail.com
- Phone : 91-8879018082
- IRC nick : charul at irc.freenode.net
- Blog url : https://honeycoding.wordpress.com
- Why do you want to work with the Fedora Project?
I have worked on various fedora projects and had a experience while working on them. I already had participated in GSoC last year and worked on the same project Shumgrepper and this year I would like to bring this project to its completion. Besides all this, fedora is my favorite linux distro and it gives me immense pleasure in contributing to its projects.
- Do you have any past involvement with the Fedora project or another open source project as a contributor?
Yes, I have contributed to Datagrepper, Fedora-Packages, Shumgrepper and Summershum.
- Did you participate with the past GSoC programs, if so which years, which organizations?
Yes, I participated last year i.e. in year 2014 with Fedora and worked on Shumgrepper project.
- Will you continue contributing/ supporting the Fedora project after the GSoC 2015 program, if yes, which team(s), you are interested with?
Yes, I will continue contributing to the Fedora Project even after the GSoC 2015 program. I would prefer contributing to more projects under Fedora-infra team as the projects completely intersect my area of interest.
- Why should we choose you over other applicants?
I have already been actively involved in contributing to fedora projects and have worked on this project last year thereby, having a good understanding of project codebase and its requirements. I am pretty much sure that this time i will be able to bring it to the state of completion.
Proposal Description
Overview and The Need
Shumgrepper is a webapp which is built on top of Summershum. Summershum collects md5sum, shasum and sha256sum of every file in every package. Shumgrepper uses this information to check the integrity and duplication among different packages. It can be used to find the common or the files that have been changed among different packages by comparing their sha256 values. It also allows you to query by shum values.
- Dev instance: http://209.132.184.120/
- Any relevant experience you have
I had worked on this project last year GSoC. Besides this, I have been writing codes in Python for more than 3 years. Also, I have built many applications in Flask, webapp2, used jinja2 template and have good experience of working as a backend developer.
How do you intend to implement your proposal
1. Database Migrations: We had made some changes in the summershum schema so that Packages list page can be rendered fast. As a first step, I would be writing a alembic migration script to update current data according to the new schema. After this, it is important to check and compare the time taken and query results.
2. Running unit-tests: It's important to run unit-tests before launching the product into production in order to minimise failures.
3. Deployment: We can plan to deploy the very first version in production of shumgrepper after the above two steps would be completed. It will involve the following steps:
- First, I will have to create a rpm package. For that first I will create a .spec file which will contain all the necessary information about the software being packaged.
- Next is to add license to the package and other small steps to make it ready for packaging. Then using rpmlint to check for errors in SPEC files, RPMS, SRPMS.
- Then I will use Mock to check if we had accurately listed build dependencies and Koji to test SRPM to other platforms.
- After all this, I will create a review request on bugzilla.
4. Testing and optimisation: When it comes to compare among different packages, it does so by comparing each file of one package with each and every file of other packages to find out common or different files; the queries take too long to return results. I need to find some ways by which we can plan to optimise these queries.
5. GPL License: As we already have the information about shum values of files within packages. This can be used to find if a package is having a genuine GPL license.
6. Querying by GPL license: We can add a filter to query those packages which have a genuine GPL license.
- We can also display the count of total packages having GPL license on /packages page.
7. Testing & Documentation: This will involve testing all the end-points and their results. Also documenting everything implemented so far.
- It will also involve maintaining the package and updating it for further changes.
8. Improving the GUI: We can improve user experiences with the app by making considerable changes in the UI. This could involve:
- We can have some visualisation (in the form of bar charts) which will give an overview of the changes among different packages.
- While comparing among three packages for finding different files among the three. We can provides some stats where we list the count of differences between every two packages.
Deliverables
1. Migration of current data according to new schema. 2. Testing, debugging and finishing off project. 2. Deployment of the app 3. Manual or Documentation
Timeline
| Period | Task |
|---|---|
| May 25 | Official GSoC coding period begins. |
| May 25 - May 31 (6 days) | Phase I(Data Migration). |
| June 1 - June 09 (9 days) | Writing unit-tests |
| June 10 - June 22 (12 days) | Deployment of app |
| June 23 - July 02 (10 days) | Optimisation of queries |
| July 03 - July 19 (17 days) | Implementing check of GPL License and querying by it |
| July 20 - August 3 (13 days) | Testing and documentation |
| August 4 - August 14 (10 days) | Improving the GUI |
| August 15 - August 21 (1 week) | Final phase of the project i.e. cleaning codes, documenting everything, reviewing all the functionalities
and fixing bugs. |
| August 21 | Pencil down date |