Chromium project culture

Chromium is an open-source browser project. Many documents are listed on the official website.
The most worth learning on the official website: Many guides are very detailed and can be used to describe how to work with the attitude of the teacher to teach the students, rather than writing documents for writing. For example, "Do not be afraid to ask questions, someone will always help you on IRC ". Most articles are well written and concise, and cannot extract the main information. It is too time-consuming to translate the full text. It is better to read the original text directly. Therefore, you only need to filter out useful information instead of summarizing it yourself. Although some documents will be outdated, they are better at being complete, especially the documents of the job category, which can provide good guidance for team collaboration.
The main categories of documents are as follows:
1. development: architecture of How to checkout, compile, debug, open branches, submit code, send review and review guidelines, become committer and its responsibility description, learning path guide, development tool Usage Guide, and divide modules by function design and code specifications.
2. Test-related: Bug reporting guide, bug handling process, use of bug systems, and use of various automated testing systems.
3. Communication: communication tools, information publishing blogs, Glossary, WiFi, document indexing, online code viewing and searching sites.
4. Project Management: aims, release schedule, design concept, evolution direction, and development plan management.

Development:
For developers, there is a document summary page at http://dev.chromium.org/developers. The bottom of the page is the reference of the entire document.
Life of a chromium developer. PPT summary.
Code learning path guide.
Requirement status. Here we can see the development direction and progress. (There are various directions, and it is difficult to summarize them by yourself. There are many H5 websites ).
Information published blog.
Glossary.
Use sublime text to edit the code.

Prepare the Code:
-The code specifications must be observed.
-Tests are required, usually unit tests. The Code magnitude is reasonable.
-A large amount of Code cannot be reviewed quickly.
Run the unit test and UI test to make sure you haven't broken anything. Or ask someone else to submit it to try server.
Individual contributor and company contributor must sign the agreement respectively. After signing, the contact information will be added to the authors file. (From this authors file, we found a total of 435 independent committer and 11 companies)
Development:
Open the branch first and prepare Change List (CL ).
Git checkout-B mychange origin/Master
Echo "This describes the goat teleporter."> goats
Git add goats
Git commit
Then, submit it to Rietveld for review. The change list has templates.

Commit process:
First, submit it to try server and wait until all tests turn green. When prompted, make sure that: IRC is online and does not leave the seat.
Review system. This system is implemented by Rietveld, an open-source project.
The code in the external directory does not belong to the chromium project. The committer permission of the corresponding project is required to write and submit the code in the corresponding way.

Review:
In addition to finding the reviewer from the owners file, you can also use SVN blame or git blame to check who has edited the file.
Because chromium is a global open source project, there is a time difference between developers, the review process may last 24-48 hours. The suggestion to reduce this impact is that review reviews are more detailed.
After the review is approved, you can select Commit in Rietveld or use the command line git Cl set_commit to submit the code to commit_queue first. This is a non-committer code submission method. Committer can still directly submit code, but it is not encouraged because it has not passed tests. The reviewer provides a checklist guide for a review initiated by a non-Committer.

A contributor who has the permission to submit is called a committer and has no permission but contributes code in other ways.
Become committer:
To put it simply, submit 10 to 20 valuable patches and ask at least 3 different people to review them. Then ask someone to nominate you as a committer candidate and obtain support.
Prove yourself:
-Commitment to contribute to this project (more than 10 good patches take a lot of time)
-Good collaboration with teams
-Understand how the team works (rules, tests, review processes, etc)
-Understand the project code basics and coding style
-Write the code.
Please send a committer to [email protected] to nominate you. The content includes:
-Your name
-Your email address. You need to get the email address of @ chromium.org.
-Explains why you must become a Committer.
-Revisions list of the patches you submitted
Two other committer s are required to support your nomination. If there is no objection within five working days, it will pass. If someone opposes or needs more information, the committer will discuss and reach an agreement within five working days. If the problem persists, it will be resolved by voting. These two reasons are usually opposed: more patches need to be submitted; not enough people are familiar with your work.
After passing the command, you will get the write permission of SVN or git and add it to the contact group [email protected.
You do not need to do anything else to maintain the committer identity.

Commit queue:
This is an automated tool to help submit the Rietveld change code. Before that, committer needs to run the script locally to run the integration test on try server. The working principle is to go to the codereview system to get the closed and the tasks to be commit, and continuously initiate the try server test in the queue. There are some more intelligent designs, so there is no need to study them in depth.

If you want to add a new function, you can post to the discussion group first. If the modification is based on the existing code, you can find the owners file in each directory and find the owner for discussion.
Not all bugs in the bug system have been assigned to you. If you are interested, you can request this bug for your solution.

Devtools: you are welcome to contribute code, development tools, and documentation.

Test related:
Get the bug editing permission:
Anyone can report bugs and add comments, but additional permissions are required to add tags, Mark duplicates, and change the status.

Before submitting a patch, you must pass the test on the try server. If you do not want help from others, you can apply for the try permission separately. You can get @ chromium.org and enter the application form, or ask the partner to send an email to [email protected] to apply.

Try Server:
Is a standard buildbot and a series of slave. The resulting lkdr (last known good revision) will be published at http://chromium-status.appspot.com/lkgr. Try server is not a suitable UC for fast iteration.

Bug system:
Bug list: https://code.google.com/p/chromium/issues/list. This system is self-developed. It lists the versions with IDs, priorities, bug detection, iteration records, and resolved channels (stable or beta), category, status, owner, summary and tag, operating system, modification date. Links on the page are redirected to: Bug reporting wizard, advanced search, and search tips (TIPS, such as special keywords, conditional search, and attachment search ), pay attention to a label by yourself (emails will be sent if such bugs exist ).
Reported bug page: http://code.google.com/p/chromium/issues/entry
Mac and Linux bug reporting guide: describes the steps for reporting bugs and demonstrates a good report.
Guide to Reporting crash bugs: chrome can open and upload crash reports. Settings> Advanced Settings> check to automatically send usage statistics and crash reports to Google. Then you can open chrome: // crashes to view the crash ID. Android manual collection: the crash report path is/data/$ package/Cache/crash \ reports /. Or run ADB shell bugreport to collect system information.
Basic requirements:
-Make sure the latest code has this bug.
-Provides an advanced problem description.
-Detailed reproduction steps
-Contains the expected behavior
-Check whether the bug exists in other browsers.
-If the test process (such as the page) can be simplified, a simple test can be made and appended to this bug.
Guidelines for Handling bugs that impede release.
Guidelines for reporting no response bugs.
Guide for reporting security bugs.
Guide for handling a bug. (Very meticulous, it is worth reading and learning how to write such documents)

Communication:
Communication Method:
Discussion groups: differentiate topics, such as regular discussion groups, plug-ins (for chromium) discussion groups, installable web apps (for chromium) discussion groups, and HTML5 discussion groups.

IRC (Internet Relay Chat): an online chat room. Clock speed: irc.freenode.net/#chromium

Wiki: most of them are special work skills.

Useful urls: Commonly Used URL collection at work.
All versions released: including version, release date, operating system, SVN version, WebKit version, and changelog.
The last 100 compiled OK versions.
Online Submission history.
Committer directory.
Search code online.

Project management:
Product goals: fast, secure, stable, and simple (easy to use ). (From the perspective of purpose, resource consumption is not the top priority)

Different Release versions are called different channels. There are five types:
Stable stable edition: It is fully tested by the test team to avoid crashes and other problems to the maximum extent. A minor version is updated almost every two to three weeks, and a major version is updated in six weeks.
BETA: has minor risks. It is updated every week and released one month ahead of the stable version.
Dev: Updated in one or two weeks. It has been tested, but there are still bugs. To help users try out what is added in the next version as soon as possible
Canary version: Updated daily. Released after being built without testing or use. Has its own configuration (File) and setting options, and can coexist with versions of other channels. Report crashes and statistics.
Other builds: chromium has a continuous integration system. You can download the version of lgtm (look good to me.

Release schedules and information.

Blink: http://www.chromium.org/blink
An open-source project also has the mission to improve the Open Web through technological innovation and good citizens.
Tips for converting from WebKit to blink.
To promote the development of web platform (which can be understood as a platform provided by web developers, simple understanding is the development standard), new functions and useless things will be added and deleted. API design is transparent, reliable, and compatible.
Process for adding new features:
1. determine whether your changes need to follow this process: if the changes do not affect the functions open to the Web, you do not need to use them. If the impact of your changes is insignificant, as long as the reviewer does not oppose it, you can skip this process; if your change cannot be implemented on Blink, send an email to the chromium team.
2. Add an item on chromestatus.com to track the status of new features and wait for feedback from others.
3. Implement new functions
4. Email to blink-Dev and wait for three lgtm instances.
5. This new function is enabled by default.
The review of the new API will be discussed by email.

Blink architecture change:
When chromium is started, the original intention is to minimize WebKit changes, but now we can make larger changes without worrying about interrupting WebKit users.
One change is to put iframe in the sandboxed process, because it is very different from other WebKit branches, so it is always delay.
Another change is to improve the network. Because WebKit's existing network APIs are mostly designed for the old Mac system, they are outdated and contain many bugs.
Finally, we implemented the entire DOM in Javascript. This greatly accelerated JavaScript access to the Dom, but it also caused a very large architecture rewrite. Therefore, we will not consider compatibility with JSC. Other considerations:

• Allow WebCore to record the history of multiple processes (currently single-process synchronous access)
• Delete the widget tree (this is the limitation of MAC webkit1)
• Split WebCore into modules
• Try to move the DOM into the Javascript heap
• Increase the utilization of multiple cores (HTML parsing, layout, and JS parsing)
• Delete the hard-to-understand parts of the Dom and perform backward compatibility to optimize performance and Remove complexity.
• Use tcmalloc on Mac
• Try incremental or parallel formatting
• Delete scriptvalue/scriptstate to solve Memory leakage, because there is only one JS engine.
• Delete custom JS bindings code
• Dom3 events/UI events
  Implemented:
• Replace the WebCore platform code with the sandbox platform API
• We recommend that you use a simpler and stricter internal system without considering two JS engines.
• Use webidl to replace webkitidl

It is not necessarily accurate because I only understand a lot. What I admire is that many tools and systems are easy to use if they are not available. Simply develop them on your own. I believe many engineers are eager for this. Reprinted please indicate the source: http://blog.csdn.net/hursing

Chromium project culture