Hacking with Bonsai

この記事はまだ日本語に翻訳されていません。MDN の翻訳はボランティアによって行われています。是非 MDN に登録し、私たちの力になって下さい。

Hacking Mozilla With Bonsai

Bonsai was originally created to solve the problem of tree instability. The original Navigator code base had large sections that were shared across multiple platforms. Many times, code checked in would compile or run on a handful of platforms. Also, with as many as 100 engineers, it was very difficult to determine what happened in the tree that caused the instability. Bonsai was created to solve these problems.

The Process

  1. Everyone who checks into the tree, joins a group called "the hook"
  2. At 8:00 AM PST every weekday morning, the source tree is closed.
  3. The build team will then pull the 8:00 AM tree, and build it on a subset of the platforms, Linux, Win32 & MacPPC.
  4. At 10:00 AM, everyone who is on the hook is available in case the build breaks
  5. Eventually, the tree builds, and it is re-opened.
  6. There is a web page, which records
    1. If the tree is OPEN or CLOSED
    2. What the date stamp of the last known good tree is
    3. Who is on the hook for the current tree
  7. Before the tree is opened, the list of checkins that happened when the tree was closed is reviewed to insure that only build related checkins took place.
  8. Before the tree is opened, there is a car pool lane where people who have been off on a branch and need a stable tip to merge in can pull the tip for their merge. These people, when they check in, will be "on the hook" for the next day's build. The car pool lane is only available to those who arrange access ahead of time with the release team.
  9. When the tree is re-opened, the web page is updated and the hook is cleared.
  10. Use the bonsai query tool to see what's been checked in to the tree lately and to look at differences between versions. Read the introduction to bonsai for more information about queries.

The rules

  1. No checkins when the tree is closed unless you are fixing a build problem at the request of a build person.
  2. If you are on the hook, your top priority is to be available to the build team to fix bustages.
  3. If you are on the hook, you are findable. You are either at your desk, or pageable, checking e-mail constantly, or on IRC so that you can be found immediately and can respond to any problems in your code.

Helpful Attitudes

  1. The build team are your friends. They are doing a not-so-fun job, so treat them with respect.
  2. People are "on the hook" collectively. Don't just blame a certain team and walk away.

Document Tags and Contributors

Contributors to this page: Jimb, Sevenspade
最終更新者: Sevenspade,