Rahulrrixe (talk | contribs) No edit summary |
Rahulrrixe (talk | contribs) No edit summary |
||
| Line 135: | Line 135: | ||
;The review process will be distributed as | ;The review process will be distributed as | ||
<strong>Watcher</strong> - who is interested in getting reports on repository <br\> | <strong>Watcher</strong> - who is interested in getting reports on repository <br\> | ||
<strong> | <strong>Contributor</strong> - who has created module/code that is being reviewed; <br\> | ||
<strong>Reviewer</strong> - One or more developers that review the module. <br\> | <strong>Reviewer</strong> - One or more developers that review the module. <br\> | ||
; | The minimum number of persons for an effective code review is at least 3. The obvious author, a moderator and at least one reviewer. This widens the probabilities of potential bugs being found. | ||
The formal process is the following: | |||
Developer creates the code | |||
Developer creates a DRR - Document Review Report - where it states the code that is being reviewed. | |||
The classes and CVS revisions that are being reviewed; | |||
The roles for the code review and the persons assigned to each role; | |||
The CVS tag that marks the code being reviewed on the source control system. | |||
The CVS tag that will mark the code after modifications resulted from code review are applied by the author. | |||
Code review meeting is scheduled by author. | |||
Code review meeting is done. The defects found are recorded in the DRR. | |||
The author corrects the defects and signs the DRR saying that the modification has been done. | |||
The author tags the CVS system with the code review output tag declared in the DRR. | |||
The author hands the DRR to the moderator. | |||
The moderator checks if the modifications have been done and can be found on the source control system. | |||
The moderator signs the DRR saying that the modification has been confirmed. | |||
The moderator hands over the DRR to the quality department for archiving. If no quality department is in place the project manager should save a hardcopy of the DRR on the project folder. | |||
Example: | |||
Developer John Doe creates a Math class that adds two numbers. He does his best to put some bugs to test the code review process. | |||
public static class MyMath { | |||
public static int Add(int a, int b) { | |||
return a - b; | |||
} | |||
} | |||
He puts his code in the source control system and the class MyMath.cs gets revision 1.1. | |||
Then he goes to write the DRR - Document Review Report. | |||
Modules/Classes | |||
MyMath.cs myproject/implementation/common/MyMath.cs (1.1) | |||
Roles | |||
Moderator - Jill Goner jill.goner@example.com | |||
Author - John Doe john.doe@example.com | |||
Reviewer #1 - Matt Groening math.groening@example.com | |||
Tags | |||
Input - PROJECT_0_0_1_INPUT_REVIEW | |||
Output - PROJECT_0_0_2_OUTPUT_REVIEW | |||
John Doe tags the current MyMath.cs revision 1.1 with the tag PROJECT_0_0_1_INPUT_REVIEW on the source control system. | |||
John Doe schedules the meeting. | |||
The meeting takes place and the defects are marked on the DRR. The total count of defects is also included. | |||
John Doe goes and makes the changes on the source code and commit the modified revision to the source control system. | |||
John Doe applies the output review tag PROJECT_0_0_2_OUTPUT_REVIEW. | |||
John Doe signs the DRR and gives it to the moderator Jill Goner. | |||
Jill Goner goes ahead and checks that the modifications were done and that the output tag was created. | |||
Jill Goner signs the DRR and hands it over to the SQA (Software Quality Assurance) engineer. | |||
Aside hint - Keep code reviews under a 2 hour maximum length. Humans tend to oversee important things mostly when reviewing code when the code reviews sessions are lengthy. It is better to split a review among more sessions that try to do it all at once. | |||
* Ask Questions and get answers — right in the code | * Ask Questions and get answers — right in the code | ||
Revision as of 02:33, 25 March 2015
Project Title : Fresque
|
Contact Information |
|
|
About Me |
|
|
Q&A |
I have been using Fedora for past five years and I am fond of its user friendly interface and reliable support forum's. In past, I have contributed to fedora-infra tahrir project and I must say that I had "great learning experience" while interacting with my mentor. I like fedora community and find everyone very helpful and motivating. In last few years, I have found some great projects has been started in fedora-infra like ptogit, shumgrepper, fresque etc, to which I would like to contribute.
Yes, I have contributed to fedora-infra tahrir project. I have made contributions to several other open source organizations i.e. Apache, Mozilla. Apart from these I have also made contribution to python projects on github i.e. Python-Cliff and Python-Click.
I have 3+ years experience in Python language which is basic required skill of the project. Fresque project is a flask app and I know the framework very well. Apart from these, I have experience in writing unit tests, handling database and also coming up new ideas. This project will involve development in flask, sqlalchemy, pygit2, unittests etc, which I know pretty well. I have already gone through the fresque project workflow and made few contribution to the project and thus, I think it makes me a strong candidate for this project.
I have made few contribution to the fresque project. Link to contribution is here
Yes, Last year I have participated for the Apache. The project was about developing command line application for Libcloud API. The project repository is available on on my github page.
I would love to work more with Fedora-Infra team because their projects intersect with my interests. I was working on Progit, Tahrir for some times and after GSOC, I would like to contribute to these projects as well as fresque.
In early May our summer vacation of college will start and ends by late of July; I can give my full time commitment to this project,. I assure dedication of at least 40 hours per week to the work and that I do not have any other obligations from early May till mid August. |
|
Past Experience |
|
In past I have made contribution to various projects of Mozilla and Apache foundation. Recently . Moving ahead, I have also written two open source libraries i.e.
which are available on pypi. Apart from this I have cofounded "Prequell" whose first project was scaling Flask application using blueprints and celery. Finally, I consider myself as an experienced Python developer as I have built various application across different domain using it.
|
|
Goal |
|
Fedora Fresque is a standard Python web application that abstracts away intricacies in package review process. Currently for any package to enter the fedora repository has to go through the manual review process, during this period they receive valuable feedbacks but once the package gets imported; all the information is lost. So, I will develop a web application which will expose dedicated RPM reviews using inline comments along with some level of automation. This will bring up lot of new possibilities to package manages and will allow them to connect to the packaging reality. |
|
Project Details |
|
The project will consist of 4 main phases: |
|
Phase 1: Add git server on backend |
|
The current process of package review have no git integration and with every new build of the package we looses the information of previous one. It means we are depriving the evolution of the spec file. Adding git will help us to track all the changes.
For example: Rahul submitted spiderman package for review and update his package with .spec file. The process using git will look like below. $ git clone git@fedorareviewserver.org:/var/git/rahul/spiderman.git $ cd spiderman && touch spiderman.spec $ git add spiderman.spec $ git commit -m "initial commit" $ git push -u origin master
For every target release their will be separate branch in order to avoid the conflicts during revive process. To keep it more general, the branch name will be given as fNN such as f14 for Fedora 14. This will be set to the default master branch.
Every new push can invoke fedora package review which will build the rpm for suitable target and the report generated will be sent via email to the packager. |
|
Phase 2: Streamlining review process |
|
During package review (in which reviewers looks for the package before sending it to the fedora server) reviewer tries to identify bugs, gives feedback and keeps code more maintainable. So to facilitate this currently fedora packaging review uses Bugzilla which is more like a bug tracker tool than reviewer and feedback is given by creating Bugzilla ticket. Furthermore, we don't have support inline comments on the packages files. So in this phase the task would be to add features which will facilitates efficient and reliable bidirectional review channel.
Watcher - who is interested in getting reports on repository <br\> Contributor - who has created module/code that is being reviewed; <br\> Reviewer - One or more developers that review the module. <br\> The minimum number of persons for an effective code review is at least 3. The obvious author, a moderator and at least one reviewer. This widens the probabilities of potential bugs being found. The formal process is the following: Developer creates the code Developer creates a DRR - Document Review Report - where it states the code that is being reviewed. The classes and CVS revisions that are being reviewed; The roles for the code review and the persons assigned to each role; The CVS tag that marks the code being reviewed on the source control system. The CVS tag that will mark the code after modifications resulted from code review are applied by the author. Code review meeting is scheduled by author. Code review meeting is done. The defects found are recorded in the DRR. The author corrects the defects and signs the DRR saying that the modification has been done. The author tags the CVS system with the code review output tag declared in the DRR. The author hands the DRR to the moderator. The moderator checks if the modifications have been done and can be found on the source control system. The moderator signs the DRR saying that the modification has been confirmed. The moderator hands over the DRR to the quality department for archiving. If no quality department is in place the project manager should save a hardcopy of the DRR on the project folder. Example: Developer John Doe creates a Math class that adds two numbers. He does his best to put some bugs to test the code review process. public static class MyMath { public static int Add(int a, int b) {
return a - b;
}
} He puts his code in the source control system and the class MyMath.cs gets revision 1.1. Then he goes to write the DRR - Document Review Report. Modules/Classes MyMath.cs myproject/implementation/common/MyMath.cs (1.1) Roles Moderator - Jill Goner jill.goner@example.com Author - John Doe john.doe@example.com Reviewer #1 - Matt Groening math.groening@example.com Tags Input - PROJECT_0_0_1_INPUT_REVIEW Output - PROJECT_0_0_2_OUTPUT_REVIEW John Doe tags the current MyMath.cs revision 1.1 with the tag PROJECT_0_0_1_INPUT_REVIEW on the source control system. John Doe schedules the meeting. The meeting takes place and the defects are marked on the DRR. The total count of defects is also included. John Doe goes and makes the changes on the source code and commit the modified revision to the source control system. John Doe applies the output review tag PROJECT_0_0_2_OUTPUT_REVIEW. John Doe signs the DRR and gives it to the moderator Jill Goner. Jill Goner goes ahead and checks that the modifications were done and that the output tag was created. Jill Goner signs the DRR and hands it over to the SQA (Software Quality Assurance) engineer. Aside hint - Keep code reviews under a 2 hour maximum length. Humans tend to oversee important things mostly when reviewing code when the code reviews sessions are lengthy. It is better to split a review among more sessions that try to do it all at once.
Ask questions about the code you use, and get answers from our community of experts, using full Markdown with syntax highlighting and symbol linking.
|
|
Phase 3: Fedora-Review integration |
|
No automatic QE during review. Fedora-Review implements API which removes many manual process in review process by doing automatic checks. People use own spreadsheet and other tools to keep track of changes. unclear for what you are waiting for. People forget about fedora flags. Bugzilla don't know about fedora relationship. like who is packager and who is the reviewer. Review Server: Git enabled server which also contains lookaside cache and tools and automation tools. every push will upload new tarball
|
|
Phase 4: user friendly GUI and robust unit tests |
|
Deriverables |
|
|
Timeline | |||||||||||||||||||||||||||||||
|
