KLF_chromium02

1Samsung Open Source Group
Chromium Contribution Process
Explained
a.k.a. Writing good patches
Adenilson Cavalcanti
MSc. BSc.
Samsung Open Source Group
a.cavalcanti@samsung.com (or
cavalcantii@chromium.org)

Why Are We Here?
l Share some lessons learned while contributing to
Blink/Chromium (and other open source projects).
l Start the discussion about good practices.
l Explain some cultural aspects of the Chromium
community.
l Present tips and tricks of the trade.

Presentation Structure
l Chromium contribution workflow explained.
l 5 Principles to make good contributions.
l Tips.
l Best practices working with Chromium team.

4
Blink Contribution Workflow
Explained

The Workflow in a Nutshell
l Associate your @company email to a Google
account.
l Checkout and build.
l Implement a change.
l Create a branch.
l Run the tests.
l Push to remote.
l Kick the bots (or ask someone to do it).
l Ask for review.

6
Create a Google Account
• Visit: https://accounts.google.com/SignUp
• Use your @company.com account.
• You will receive the validation link through your
email.
• The password can (and should) be different.

Create a Google Account

8Samsung Open Source Group *if a colleague has a checkout, use a pendrive to copy.
Checkout
l Install depot tools:
l git clone https://chromium.googlecode.com/
chromium/tools/depot_tools.git
l Export PATH=$DEPOT_FOLDER
l Checkout the code* (21GB)
l mkdir chromium; cd chromium; fetch –nohooks
chromium; gclient runhooks
l Update: git checkout master; git rebase-update;
gclient sync --jobs=16
l Further info:
http://dev.chromium.org/developers/how-tos/get-the-code

Build
l Beefy hardware: 64 bits + 16GB ram.
l Intel i7@2.5Ghz takes 45 minutes.
l Uses +30GB of disk space.
l Building*:
l ./build/gyp_chromium –Dwerror= #configure
l ninja -C out/Debug/ blink_tests -j10 #layout tests
l ninja -C out/Debug/ content_unittests -j10 #content
l Targets: unit_tests | browser_tests | net_unittests |
gpu_unittests
l ninja -C out/Debug chrome -j10 #chromium browser

Patching
l Make a change, create a branch and commit:
l git checkout –b myFeature
l git commit -a -m “It does something.”

Running Tests + Upload
l Layout tests:
l ./Tools/Scripts/run-webkit-tests --debug css3/filters
l Content tests:
l ./out/Debug/content_unittests | unit_tests
l If everything is ok (i.e. no regressions), upload
the patch:
l git cl upload
l Kick the bots:
l git cl try #Alternatively, use a browser to select bots

12
2. Develop patch
7. Land patch
Retry 3x
Manual commit
Submitting Patches

Watching the Bots
Bots are computers that will apply your patch on
top of master and test (i.e. compilation, layout
tests, etc)
l You should receive emails about bot status.
l Investigate if a bot is red.

Blink/Chromium: Gaining Status
Committer:
• Same as WebKit (30~40 non-trivial patches).
• Bonus if already a WebKit committer.
Owner:
• Have provided high quality reviews / design feedback.
• Be a Chromium project member for at least 6 months.
• Have submitted a substantial number of non-trivial changes.
• Had made changes to the affected directory within 90 days.
• Bandwidth to contribute with other owners.

15
5 Principles To Make Good
Contributions

The Magic Secret to a Good Patch
l Answer these 5 questions.

The 5 Magical Questions
l Does it improve performance?
l Is it an enabler for others?
l Is it spec compliant?
l Is it innovative?
l Does it fit the project architecture?

If Everything Fails…
l Does it improve the performance?
l Is it an enabler for others?
l Is it spec compliant?
l Is it innovative?
l Does it fit the project architecture?
Does it at least cleanup the code remarkably?

19
If the Answer is No…
Give up and try something different.

Final Consideration
l Submit something you are proud of.
l Put yourself in the reviewer’s shoes.

Final Consideration
l Submit something you are proud of.
l Put yourself in the reviewer’s shoes.
Remember: you are putting your name on
the line in addition to your company image.

Writing Good Commit Logs
l To be useful, a log must foremost describe why a
change was made (the what is obvious by
reading the code).
l Programmer types:
l poor programmers don’t write logs;
l good programmers write logs that need the code to
be understood;
l great programmers write logs that are self
explanatory and may include references to external
documentation.

Writing Good Commit Logs
l Bad log: “fix bug and refactor.”
l Good log example:

Commits Must Be Atomic
l Do one change (e.g. implementing one feature)
and resist the urge to add non-related things (e.g.
aesthetics, typos, etc).
l If you identified something else, open a new bug
to track the issue and submit another patch later.

Quality X Quantity
l 3 good patches are much better than 15 obvious
ones.

1 Ferrari F12 == 16 Fiat 500.
Quality X Quantity

Self-Review Your Code
l When you are done, look for possible areas for
improvement.
l Try to find cases where it would fail.
l Does it scale up? Does it scale down?

Know Thy Browser
l Have all browsers handy and know their behavior
for what you working on.

Know the Code Style
l Before starting anything, read:
l https://www.chromium.org/developers/coding-style
l https://www.chromium.org/blink/coding-style
l Fix the mistakes pointed by ‘git cl upload’.

31
Best Practices Working with
Chromium Team

Communication is King
l Think twice and formulate your thoughts in an
articulated way.
l If you have difficulties with English, prefer async
comm (e.g. mailing list).
l Go straight to the point, time is valuable.
l The way you speak may affect how reviewers
may perceive your ideas.
When using IRC:

How to Ask Smart Questions*
l Do your homework:
l research;
l read available documentation;
l ask your team members;
l Write the question with a clear title.
l Proof read before posting.
l Add links to each relevant info you found (to
prove that at least you tried to find answers).
*Reference: http://catb.org/~esr/faqs/smart-questions.html

Know the Time Zones
l The team is distributed (from Korea):
l California is 16 hours behind.
l Europe (UK) is 8 hours behind.
l Sometimes you will have to wake up earlier (or
wait for late night) to reach the right person.

Observe Cultural Differences
l Code review is straight and to the point.
l The criticism is directed at the code, not at you as
a person.
l Any accepted contribution brings a cost for
maintenance and has to be within the high
standards of the project.

Observe Cultural Differences
l USA: it is alright, OK.
l Russia: zero.
l Brazil: insult!

Choose an Area and a Reviewer
l Select an area/subsystem to work on.
l Develop a relationship with one or two reviewers.
l Avoid jumping from one area to another as it will
impact your productivity and your potential
nomination to become a committer in the future.

Use Bots Sparingly
l Bots consume resources and many queued jobs
slows down every single contributor.
l Only select 3 or 4 bots (e.g. mac, windows,
android, linux-debug) and submit the job if you
have tested it locally.
l Recently a developer almost had bot permissions
blocked because he was ‘trigger happy’.

Use Bots Sparingly

When to Duck
l Generally, the reviewers are right when they ask
for changes.
l Be grateful for the feedback and implement all
changes.
l Don’t push back or stall (especially if you are not
used to the subsystem you are working).
l Again: the reviewers are doing you a favor by
reviewing your patch.

When to Duck

When to Hold Your Ground
l If you truly believe your idea makes sense and
have done great research.
l If you have data (e.g. benchmarks).
l When you can point to specs (W3C, WHATWG).
l When other browsers implement the same
behavior.

The Job is Never Completed
l After a patch has landed, keep watching the bots
for any regressions:
l http://build.chromium.org/p/chromium/waterfall
l If you noticed that your patch is responsible for a
regression, ping the reviewer in IRC and discuss
what to do next.

Check Your Email on the Weekends*
l It may happen that your contribution triggered a
regression and in such case you will be notified by
email.
l Promptly answer the email and start
investigating.
l If not possible, suggest to rollback the patch and
explain when you can start looking into the
subject.
*if you can’t, time your patches with
weekdays (e.g. Tuesday/Wednesday).

Check Your Email on the
Weekends
This happened
in a Friday at 23hs!

Follow the Mailing List
l Be aware of what is happening in the project as a
whole.
l Sign in to blink-dev and chromium-dev.
l Before starting something bigger, ask reviewers
what they think about it.

Questions and Answers

Thank You!

KLF_chromium02

Recommended

Recommended

More Related Content

Similar to KLF_chromium02

Similar to KLF_chromium02 (20)

KLF_chromium02