#Chromium

I record the steps I took when I first contributed to Chromium and the precautions I took. Since Chromium is a large open source community, the related procedures are introduced in great detail. If you do a search, there are many third-party posts that you can refer to. I mainly referred to the following three sources. The first two are official documents provided by the Chromium community. The last one was written by a third party, and it was written more friendly and easy, helping to intuitively and quickly understand the contribution process.

1. Signing the CLA(Contributer License Agreement)

To contribute code to Chromium, you must sign a contract called CLA. This means giving up various rights to the contributing code. It is a device to avoid legal disputes from the point of view of an open source project. To sign in, log in with your Google account, then https://cla.developers.google.com/ and follow the procedures in

2. Git settings

Chromium’s code contribution is governed by a code review system called gerrit. To comply with this control, I need to properly configure git on my development machine by executing the following commands in order. The name and email address must be entered correctly as they are used to identify the contributor of the code uploaded to gerrit and to send various notifications related to the code to the contributor.

git config --global user.name "내 이름"
git config --global user.email "myemail@chromium.org"
git config --global core.autocrlf false
git config --global core.filemode false
git config --local gerrit.host true

3. Hunting or Searching bugs

What if you could find and fix bugs in Chromium yourself? If so, you must be a master who combines the skills of a bug hunter and a developer at the same time. In particular, since Chromium has been actively developing for a long time, it is not easy to find bugs. Of course, you can contribute by suggesting a new function and implementing it, but in that case, it will be more difficult to convince other developers through a mailing list and design and develop the function together.

Chromium provides a bug tracking management system. If you visit https://bugs.chromium.org, you can see a list of bugs reported by Chromium users around the world. can Any bug in the “available” state can be challenged. In particular, bugs labeled “GoodFirstBug” are said to be a good challenge for developers who are new to Chromium. There is a filter function, so you can search easily.

4. Building Chromium

After receiving and building the Chromium source code, reproduce the bug, and analyze the cause. The relevant procedure is [Get the Code: Checkout, Build, & Run Chromium](https://www.chromium.org/developers/how-tos/get-the-code “Get the Code: Checkout, Build, & Run Chromium” “) for each platform in detail, so please refer to it.

It is recommended that you work on a separate branch to analyze or fix the cause of the bug. Branches, a function provided by git, are independent of each other and are mainly used for collaboration. Here, it is used for the purpose of fixing several independent bugs at the same time. The following command creates a branch called “mychange” and switches to that branch at the same time.

git checkout -b mychange -t origin/master

5. Fixing the bug

There are things to be aware of when the content of a bug is not a simple problem of fixing comments, but a problem that requires function correction, etc. If there is a function for testing the function to be modified, the code for testing the code to be contributed must also be contributed. It’s cumbersome. However, since the bug may reappear in the future, it is necessary to track the bug, which is a very important part of the open source community. Even if you omit it, you may be asked to add test code from a reviewer later, so it is better to keep this in mind in advance. For testing, refer to Testing and infrastructure.

Chromium’s code must be written according to the coding style rules set by Google. Therefore, the code to contribute should also be written according to this rule. The command below automatically checks whether the modified code meets the rules. I do not know to what level the inspection is performed, but personally I was able to confirm that unnecessary blanks were removed.

git cl format --js

Also, if you are contributing to Chromium for the first time, you must add your name and email to a file called “AUTHOR” on a single line. When appending, be aware that these files follow a lexicographical order. Finally, when the contribution is completed, there is a solid basis for the title of “contributor”.

Any edits you wish to contribute must be put into a ready state for upload to gerrit. To make the modified code batch ready for upload, use the git command below.

git add .
git commit -a

6. Uploading the code

You can upload the prepared code to gerrit with the command below. At this time, you are asked to write a brief summary of the revised content. In this summary, you should briefly describe which bug you are trying to fix, and which code you modified and how. Above all, this summary should be prepared with great care as it is a publicly available content. As such, there are rules that must be followed when writing. For this reason, if you are unfamiliar with English and contributing to Chromium, it is better to prepare a summary in advance.

git cl upload

The summary consists of two parts: the title and the body. How to Write a Git Commit Message explains in detail how to write a good summary. Below is a summary of the rules to be followed when writing a summary.

  1. There is no such person, but it must be written in English, the universal language.
  2. The title should start with a capital letter and be one line. It is recommended that you write less than 50 characters, but I think it will be okay if you exceed it a little.
  3. One blank line must be inserted between the title and the body. gerrit separates the title and body of the summary based on this blank line.
  4. Like the source code of Chromium, the width of the body should not exceed 72 bytes.
  5. Write the issue number of the bug you want to solve. When a contribution is made, information about the contribution is automatically registered in the form of a comment on the corresponding bug in the bug tracking management system. That is, through this, the bug tracking management system and the code review system are linked.
  6. If possible, describe a method to check whether the bug has been resolved.

Below is an example of writing a summary provided by the Chromium community. For more examples, please visit https://chromium-review.googlesource.com.

Summary of change (one line)

Longer description of change addressing as appropriate: why the change
is made, context if it is part of many changes, description of previous
behavior and newly introduced differences, etc.

Long lines should be wrapped to 72 columns for easier log message
viewing in terminals.

Bug: 123456
Test: Load example.com/page.html and click the foo-button; see
crbug.com/123456 for more details.

7. Code review

If you have completed uploading and entered your name and email address correctly when setting up git, the website provided by gerrit is [https://chromium-review.googlesource.com](https://chromium-review.googlesource.com You can check the uploaded content at “https://chromium-review.googlesource.com”). However, no contribution has been made yet. You can see the status is “WIP (Work in progress)”, which means it’s still working. In this state, it is possible to edit the contribution content through multiple uploads even afterward. If you think you’re perfect to contribute, you should get a review, or correction, from a reviewer. Adding reviewers is done on the web. Who to add can be recommended through the git command below. Just add 2 or 3 suitable reviewers. Finally, when more than one review is received, the changes are automatically reflected in the Chromium code repository https://chromium.googlesource.com/chromium/src.git, thereby completing the entire contribution process.