How to participate in the open source project Chromium
In the q & a section of Habr there are quite a few questions from people choosing an open source project in which they would like to participate: one , two , three , four , five .
I think many have heard about the Google Chrome browser and about the fact that it is based on the open source project Chromium. It so happened that during the past year I managed to make a small contribution to this project as an independent developer (that is, I have no relation to Google and do this project in my free time). In the process, I naturally had to deal with some technical and organizational issues, which I would like to share.
Below I will talk about how to build Chromium at home, how to choose a task from the system of bug tracking and how to make your code in the repository.
')
First of all I want to say that at www.chromium.org/Home there are detailed instructions for all occasions - starting with getting the source code and ending with instructions for sending your patches to the commit. In addition, I recommend reading this document and follow the links in it.
An independent developer process consists of the following steps:
Below - more about each of the steps.
The assembly requires a fairly modern computer, various documents on the above site recommend a multi-core processor and at least 8 GB of memory. In addition, you will need about 60 GB of free hard disk space, which is recommended to use a separate SSD.
The source code can be retrieved from the repository using SVN, but since the amount of code is significant, it is recommended to download the archive, deploy a copy from it on the local machine and then update it from the repository. The size of the archive is slightly less than two gigabytes.
Read more here: dev.chromium.org/developers/how-tos/get-the-code
Before assembly, it is necessary that all necessary packages / SDKs are installed on the machine. Each platform has its own detailed instructions, for example, for Windows - here ( www.chromium.org/developers/how-tos/build-instructions-windows ), for Linux - here ( code.google.com/p/chromium/wiki / Linbubuildinstructions ).
Now a little about my personal experience. All figures will be given approximately and exclusively from memory, records, unfortunately, did not.
I managed to build Chrome under Windows and Linux. Under Mac OS, linking failed, although the compilation was successful.
To build under Windows, a five-year-old computer with a dual-core processor and 3 GB of memory was used. The complete build took about 6 hours (I can not say more precisely, I put the build for the night), plus linking - more than half an hour (on 32 bits it turned out impossible to enable incremental linking).
To build the Linux version, a virtual server in the cloud was rented from one of the Russian hosters. Resources are allocated there on demand and about 8 GB of memory and 8 processor cores were used in the build. Payment there is charged for the resources used and the build from scratch cost, it seems, 35 rubles. Full build time is about an hour.
To build under Mac OS, the hackintosh was used in a virtual machine, the compilation took more than ten hours. I did not test the build under this OS, I just made sure that my changes did not break the build.
As one of Google’s employees told me, the developers working on Chrome use two builds with different operating systems of their own choice. He also added that Chrome differs from Chromium only in the presence of several proprietary modules and a logo. The Google employee’s workflow for Chrome is the same as the independent contributor’s workflow, except that the Google employee has access to some private entries in the bug tracker, such as security.
If the build is successful, you can find an open bug and try to fix it. All browser related defects are located in the bug tracker at code.google.com/p/chromium/issues/list .
Novice developers are advised to choose bugs with the GoodFirstBug tag. It is assumed that tasks with this label are simpler and a person who has a weak idea of ​​the code will be able to deal with them quickly enough.
In this step, you already have a working build and the selected bug. All you have to do is try to reproduce the bug and find out its cause, using a debugger and a good sense. I used Microsoft Visual C ++ 2008 Express Edition (they currently recommend using version 2010).
Before fixing a bug, it is strongly recommended that you read the style guide document: www.chromium.org/developers/coding-style
Fortunately, some inconsistencies of the code to the guidelines are automatically found by the gcl utility, which is used to create a changelist before sending to the review (for example, I found spaces in the end of the line that I did not notice).
It is also recommended to have experience in developing an industrial code, since the quality requirements are quite high.
If this is your first bug fix in a project, then in addition to the changes in the code, you need to add your name to the AUTHORS file and include this change in your commit.
Review the code before the commit in the project is mandatory. If the author of the code does not have the rights to write to the repository (and this is just our case), then it is the reviewer who, as a rule, commits the code.
Before sending the code, it is necessary to create a changelist, this is done by the gcl command, see here for more details:
dev.chromium.org/developers/contributing-code#TOC-Create-a-change-list-CL-
After the changelist is created, it is sent to a system called Rietveld . Next you need to select the reviewers and send them an invitation. I searched for them by simply looking at the code change history and selecting the people who made the most commits. Details of the process described here:
dev.chromium.org/developers/contributing-code#TOC-Request-review
Reviewers usually respond to emails within 24-48 hours. In my cases there have been several rounds of reviews, and, as I understand it, this is a common practice. After all the reviewers answer LGTM (looks good to me), you can ask one of them to commit your code.
I usually just wrote something like “Could you please commit it for me?” And after a while received letters from tryserver, and then from commit-bot that the code got into the repository.
In general, the whole process left me with the most positive impressions. The code is qualitative, all organizational and technical aspects are documented in detail on the chromium.org website and in the source code. Utilities are convenient, and people are friendly.
I am pleased to answer questions in the comments.
I think many have heard about the Google Chrome browser and about the fact that it is based on the open source project Chromium. It so happened that during the past year I managed to make a small contribution to this project as an independent developer (that is, I have no relation to Google and do this project in my free time). In the process, I naturally had to deal with some technical and organizational issues, which I would like to share.
Below I will talk about how to build Chromium at home, how to choose a task from the system of bug tracking and how to make your code in the repository.
')
First of all I want to say that at www.chromium.org/Home there are detailed instructions for all occasions - starting with getting the source code and ending with instructions for sending your patches to the commit. In addition, I recommend reading this document and follow the links in it.
An independent developer process consists of the following steps:
- Collect Chromium.
- Select a bug from the Issues List.
- Fix a bug, test it.
- Send a bug for review.
- Fix review issues, go to step 4.
- Ask the reviewer to commit your code.
- Enjoy the result.
Below - more about each of the steps.
Step 1. Collect Chromium
The assembly requires a fairly modern computer, various documents on the above site recommend a multi-core processor and at least 8 GB of memory. In addition, you will need about 60 GB of free hard disk space, which is recommended to use a separate SSD.
The source code can be retrieved from the repository using SVN, but since the amount of code is significant, it is recommended to download the archive, deploy a copy from it on the local machine and then update it from the repository. The size of the archive is slightly less than two gigabytes.
Read more here: dev.chromium.org/developers/how-tos/get-the-code
Before assembly, it is necessary that all necessary packages / SDKs are installed on the machine. Each platform has its own detailed instructions, for example, for Windows - here ( www.chromium.org/developers/how-tos/build-instructions-windows ), for Linux - here ( code.google.com/p/chromium/wiki / Linbubuildinstructions ).
Now a little about my personal experience. All figures will be given approximately and exclusively from memory, records, unfortunately, did not.
I managed to build Chrome under Windows and Linux. Under Mac OS, linking failed, although the compilation was successful.
To build under Windows, a five-year-old computer with a dual-core processor and 3 GB of memory was used. The complete build took about 6 hours (I can not say more precisely, I put the build for the night), plus linking - more than half an hour (on 32 bits it turned out impossible to enable incremental linking).
To build the Linux version, a virtual server in the cloud was rented from one of the Russian hosters. Resources are allocated there on demand and about 8 GB of memory and 8 processor cores were used in the build. Payment there is charged for the resources used and the build from scratch cost, it seems, 35 rubles. Full build time is about an hour.
To build under Mac OS, the hackintosh was used in a virtual machine, the compilation took more than ten hours. I did not test the build under this OS, I just made sure that my changes did not break the build.
As one of Google’s employees told me, the developers working on Chrome use two builds with different operating systems of their own choice. He also added that Chrome differs from Chromium only in the presence of several proprietary modules and a logo. The Google employee’s workflow for Chrome is the same as the independent contributor’s workflow, except that the Google employee has access to some private entries in the bug tracker, such as security.
Step 2. Select a bug from the Issues List
If the build is successful, you can find an open bug and try to fix it. All browser related defects are located in the bug tracker at code.google.com/p/chromium/issues/list .
Novice developers are advised to choose bugs with the GoodFirstBug tag. It is assumed that tasks with this label are simpler and a person who has a weak idea of ​​the code will be able to deal with them quickly enough.
Step 3. Fix the bug, test
In this step, you already have a working build and the selected bug. All you have to do is try to reproduce the bug and find out its cause, using a debugger and a good sense. I used Microsoft Visual C ++ 2008 Express Edition (they currently recommend using version 2010).
Before fixing a bug, it is strongly recommended that you read the style guide document: www.chromium.org/developers/coding-style
Fortunately, some inconsistencies of the code to the guidelines are automatically found by the gcl utility, which is used to create a changelist before sending to the review (for example, I found spaces in the end of the line that I did not notice).
It is also recommended to have experience in developing an industrial code, since the quality requirements are quite high.
If this is your first bug fix in a project, then in addition to the changes in the code, you need to add your name to the AUTHORS file and include this change in your commit.
Step 4. Submit a bug for review
Review the code before the commit in the project is mandatory. If the author of the code does not have the rights to write to the repository (and this is just our case), then it is the reviewer who, as a rule, commits the code.
Before sending the code, it is necessary to create a changelist, this is done by the gcl command, see here for more details:
dev.chromium.org/developers/contributing-code#TOC-Create-a-change-list-CL-
After the changelist is created, it is sent to a system called Rietveld . Next you need to select the reviewers and send them an invitation. I searched for them by simply looking at the code change history and selecting the people who made the most commits. Details of the process described here:
dev.chromium.org/developers/contributing-code#TOC-Request-review
Step 5. Fix review issues, go to step 4
Reviewers usually respond to emails within 24-48 hours. In my cases there have been several rounds of reviews, and, as I understand it, this is a common practice. After all the reviewers answer LGTM (looks good to me), you can ask one of them to commit your code.
Step 6. Ask the reviewer to commit your code
I usually just wrote something like “Could you please commit it for me?” And after a while received letters from tryserver, and then from commit-bot that the code got into the repository.
Step 7. Enjoy the result
In general, the whole process left me with the most positive impressions. The code is qualitative, all organizational and technical aspects are documented in detail on the chromium.org website and in the source code. Utilities are convenient, and people are friendly.
I am pleased to answer questions in the comments.
Source: https://habr.com/ru/post/165193/
All Articles