ヨタの日々

_ 朝ッ

0520 起床

_ 仕事

0830 出勤

ドリルまわしまぁーす

_ [NetBSD][翻訳]NetBSD Blog - Interview with Soren Jacobsen

Soren Jacobsen へのインタビュー

June 25, 2009 posted by Emile Heitor

A couple of weeks ago, Guillaume Lasmayous and I threw the idea of interviewing NetBSD developers through our website, NetBSDfr, to promote the NetBSD Project, and to make their work known to the widest possible audience. Today, we are discussing with Soren Jacobsen, snj@, NetBSD 5.0 release engineer.

2, 3 週間前 Guillaume Lasmayous と私は NetBSD の発展のために我々のウェブサイト NetBSDfr で NetBSD 開発者へインタビューしよう、というアイデアを思いつき、より多くのひとに彼らの仕事ぶりについて知ってもらうことにした。今回は NetBSD 5.0 リリースエンジニアの Soren Jacobsen( snj@ ) に話を聞いた。

NetBSDfr: First of all, let me thank you for this interview. We plan to run several interviews of NetBSD developers, I think, one every one or 2 months or so. You've been chosen as the first one. Thanks for accepting to answer our questions.

snj: Thanks for asking me, and thanks for your efforts to strengthen the community. It's great to see efforts like this. Sorry it took so long to get back to you. I wanted to take some time to think over my answers. Please let me know if you think anything needs clarification.

NetBSDfr: まず最初にインタビューに応じてくれたことに感謝します。我々は何人かの NetBSD 開発者へのインタビューを計画しており、2 ヶ月かそのくらいでインタビューする予定です。最初に選ばれたのがあなたです。質問に答えてくれてありがとう。

snj: インタビューありがとう。そしてあなたがたのコミュニティへの尽力に感謝します。これはすごいことです。でもあまりあなたがたへお返しできないかもしれない。ちゃんと答えるためにはもう少し時間がほしい。説明が必要なら言って欲しい。

NetBSDfr: For the readers who don't know you, can you shortly introduce yourself ?

snj: My name is Soren Jacobsen and I am a NetBSD developer and release engineer. I've been part of releng since late 2005, and was the lead release engineer for the 5.0 release.

NetBSDfr: 読者のみなさんへ自己紹介をお願いします。

snj: Soren Jacobsen です。NetBSD 開発者でありリリースエンジニアをやっています。2005 年からリリー作業に携わり、5.0 release のリリース作業を担当しています。

NetBSDfr: Why did you choose to run NetBSD ? How long have you been using it ?

snj: My first experience with NetBSD was 1.5.3, which I guess was around the second half of 2002. Compared to a lot of people, I was a bit late to the party. At the time, I was frustrated with Linux in a number of ways, and NetBSD was a solid operating system with a philosophy that made sense to me. There wasn't any one particular thing about NetBSD that grabbed my attention. It was more that there was nothing that bothered me. It just seemed right.

NetBSDfr: どうして NetBSD の作業をしようと思ったのですか？ また、NetBSD を使い始めてどれくらいですか？

snj: 最初に NetBSD に触れたのは 1.5.3 のときでした。2002 年の半ば過ぎくらいだったと思います。すでにたくさんのひとが携わっていました( 訳: I was a bit late to the party は「このビッグウェーブに乗り遅れた」といった意味か? )。そのとき私は Linux にたくさんの不満を持っており、NetBSD の哲学にもとづいた堅牢なオペレーティングシステムに ぐっときたんです。NetBSD への関心を妨げるものはとくに何もありませんでした。何か困惑することもありませんでした。これはじつに正しいことに思えたんです。

NetBSDfr: Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?

snj: Like most volunteers, the amount I'm able to spend on NetBSD depends on real life and my motivation level. A year ago, at most I was doing 8 hours a week. More recently, 8 hours a day wasn't uncommon. The week leading up to the release was especially hectic; I put in a couple 16 hour days there.

NetBSDfr: NetBSD へどれくらい時間をかけるか何か考えてる？毎日とか毎週とか毎月とか

snj: まさにボランティアみたいなものですから、NetBSD にどれくらい時間をかけるかは、実生活とモチベーションに依存します。去年はだいたい 1 週間に 8 時間費やしました。最近は 1 日 8 時間も使うことはあまり無いです。リリース担当の週は多忙で、16 時間以上費やします。

NetBSDfr: How did you become a NetBSD developer ?

snj: When I started using NetBSD full time as my primary operating system, I became heavily dependent on pkgsrc, our framework for third-party packages. There were a number of packages I wanted to see updated, and I started sending patches against pkgsrc and various small things in the base system. At the end of 2003, I was offered an account, and became a developer in January of 2004.

NetBSDfr: どうやって NetBSD 開発者になったの？

snj: 私の最重要オペレーティングシステムとして NetBSD をフルタイムで使うようになって、サードパーティパッケージ向けの我々のフレームワークが pkgsrc にかなり依存するようになりました。いくつかのパッケージをアップデートしたくて、pkgsrc の基本システムへのいくつかの変更点のパッチを pkgsrc へ投げ始めました。2003 年末にアカウントを貰い、2004 年 1 月に開発者になりました。

To anyone out there who is interested in helping the project: pkgsrc is a great way to get involved. There are so many packages out there, and only a finite number of developers to import and maintain them. Consider submitting PRs against pkgsrc and joining the pkgsrc-wip project. We can use all the help we can get in this area.

NetBSD プロジェクトの手助けに関心のあるすべての皆さんへ: pkgsrc は NetBSD プロジェクトに深く関わるには非常によい手段です。ものすごい数のパッケージが提出され、ごくわずかの開発者がインポートし、メンテナンスします。pkgsrc へ PR を提出することを検討し、pkgsrc-wip プロジェクトに参加してください。我々が手助けします。

NetBSDfr: How did you become member of NetBSD release engineering team ? Are the members of the releng team elected ? chosen among developers ? Does this require specific skills ?

NetBSDfr: どうやって NetBSD リリースエンジニアリングチームのメンバーになったのですか？ リリースエンジニアリングチームによる投票？ それとも開発者から選ばれる？ 何かスキルが要る？

snj: The release engineering team is rather informal. There is no election process, and no strictly defined leader of the group, although people do step up to fill this position. When we feel understaffed, we put out a call for volunteers, and usually a person or two will join.

snj: リリースエンジニアリングチームはくだけてます。投票するということは無いし、ちゃんとしたリーダーというのも居ませんし、みんなこの位置に居座ります。人手不足だと思ったら人員を募集し、いつも 1, 2 人参加してくれます。

Release engineering is not as glorious as a lot of other activities, so we don't normally have people begging to join releng. It's hard to say about specific skills. Like in most other areas, having sound judgment and a good sense of perspective is essential. These are the only strictly required skills. Plenty of others are useful, though: patience, caution, attention to detail, etc. Pretty basic stuff, for the most part. Of course, the more technical knowledge, the better, but this is not as big of a deal as it might seem. I'll explain below.

リリースエンジニアリングは他の活動ほど名誉ある作業ではないので、他のひとたちに参加を勧めることはありません。ある技術については他のプロジェクトよりも難しいところがあって、判断力があり、先見の明があることが必須です。これらが求められる技術です。他にも技術があるほうがいいんですが、まあ、辛抱強さ、用心深さ、細部への注意深さ、とかいろいろあるといいです。基本的にスタッフはこれらが得意です。もちろんもっと技術的な知識があるほうがいいですが、あまり重要ではありません。そこだけははっきりさせておきます。( 訳: ???? )

NetBSDfr: Can you explain us more in details how does NetBSD release engineering process work ?

snj: There are two basic tasks:
- Pulling up changes into branches.
- Releasing.

NetBSDfr: NetBSD リリースエンジニアリングの作業についてもう少し詳しく教えてください。

snj: 基本的な作業はこう:

• current での変更をブランチに反映
• リリース

The first one is rather straightforward, and it is something we do constantly. Developers request that certain changes be pulled up to a given branch. If we agree that the changes should be pulled up, we commit them to the branch. To help track the status of a branch, we maintain a record of every change made to a branch over its lifetime.

最初のは単純明快だし、いくつか定期的におこなっています。開発者は変更点をブランチへ反映することを要求します。変更点を反映すると決定したら、ブランチへコミットします。ブランチの状態を追跡しやすくするために、ブランチの生存期間中はその記録をメンテナンスします。

Putting together a release is a much more complicated task requiring coordination with a large number of people. The main task is to decide the point at which the remaining bugs can safely be ignored. There are lots of other tasks involved here, of course: managing the build cluster, pulling up changes, preparing information about the release, testing, making sure that important fixes find their way to the branch, begging people to work on certain things, paying very close attention to the mailing lists, etc.

release の場合はたくさんのひとと調整することが要求されるのでもっと複雑です。おもな作業は、残っているバグを除去して安全にすることです。もちろんたくさんの複雑な作業があります: ビルドクラスターを制御したり、変更点を反映したり、リリース告知を準備したり、テストしたり、ブランチに重要な fix がされているか確認したり、あることについては誰かに作業してもらったり、メーリングリストへ細心の注意を払ったり、いろいろ。

NetBSDfr: How does the quality assurance process works ? Who decides to include this or that patch to a branch ? This is also linked I think to the following question: how does the releng team decide how many betas, RCs versions are required before declaring a branch is stable ?

snj: No one person can have thorough technical knowledge in all areas of the source tree. Therefore, it's sometimes hard for a person (or small group) to be able to say for sure whether a particular change should be pulled up to the release branch. This is where one of the most important qualities of a release engineer comes into place: the ability to get sound advice from the right people. To some extent, we trust that developers submitting changes for pullup have carefully considered the implications of the change. But at the same time, we try to be very cautious, and being able to effectively consult with other developers is of vital importance.

NetBSDfr: 品質保証についてはどうやってますか？ ブランチにパッチを取り込むことを誰が決めるのですか？ これは次の質問にも関連しますが、ベータ版をいくつ作るのかどうやって決めるのですか？ ブランチが安定したと判断するまでにベータやRCがいくつ必要かを、どうやって決めるのですか?

snj: ソースツリー全体について技術的な知識を持っているひとは誰も居ません。したがって、担当者( または少人数のグループ )がリリースブランチの主な変更点を反映し、それが問題ないということを告知する作業は、ときに困難になります。正式な担当者から信頼できる助言を貰うことは、リリースエンジニアがうまくやってのけるためには最重要の品質のうちのひとつです。じつをいうと、開発者は変更された部分をちゃんと反映してくれてると信じている。しかし、それと同時に、よく注意し、他の開発者にも効果的に相談することがきわめて重要です。

We start the release process when we think the tree is in pretty good shape. At this point, the branch is known as, e.g., 5.0_BETA. At this point, more users start running the code, and we are constantly watching for feedback (positive and negative). Intrusive changes are avoided during all stages of the release process, but they are most acceptable at this point. The general rule is that the further along in the release process we are, the more restrictive we are about changes. Unfortunately, it is impossible to have many hard rules about this. If big nasty bug comes up, you're faced with a choice between ignoring the problem or taking a risk on an intrusive change. Sometimes we take the risk, sometimes we don't. This is another case where no one particular person can have all the answers. To avoid one person making a bad judgment call, members of releng discuss these issues with each other and with other developers.

我々はソースツリーがじゅうぶん良い段階になったらリリース作業を始めます。このときのブランチは、たとえば 5.0_BETA などです。そして、よりたくさんのユーザーがコードを使い始め、我々は定期的にフィードバック( 良い点も悪い点も )を監視します。リリース作業の全体では変更点は受け入られづらいのですが、リリース作業開始初期は変更点を受け入れやすいです。。一般的な規則は、リリース作業について規定していて、変更点についてもっと制限をしています。残念ながら、たくさんの厳密に規則を実施することは難しいです。もし、ものすごく鬱陶しいバグが報告されたとしましょう。あなたはそれを無視するか、もしくはなんとしてでも変更し、そのリスクをとるか、どちらかを選ぶことができます。我々はリスクをとることもあるし、何もしないときもあります。これは、とくに誰もその答えを持っていないときの選択肢です。誰かが悪い意見を言った場合、それを回避するためにリリースチームのメンバーが他の開発者たちと議論します。

A release candidate, by definition, occurs when it is felt that the tree is good enough to release. In practice, this rarely happens. There is almost always a good reason to do at least one more release candidate. In some respects, they're more psychological than anything else. I admit I rushed a couple release candidates out with full knowledge that 5.0 could not be released without further fixes. But when important last-minute changes are made, putting out a release candidate is a great way to get those changes tested. Take 5.0_RC3, for example. At the time, we were aware of a few show-stopping bugs, but there were significant WAPBL changes that needed wider testing, so we felt that RC3 was justified.

release candidate は定義によると、relase するのに妥当だと判断されたソースツリーのことです。習慣ではたまに発生します。たいていいつも 2 回は release candidate を作ります。いくつかの点では、他の何よりずっと心理的です( 訳: ???? )。5.0 がいくつか fix されてないことを承知のうえで release candidate を出したことがあります。重要な点については土壇場で変更し、release candidate を出し、とてもすぐれたテストを得ることができました。たとえば 5.0_RC3 。このときはいくつかの致命的なバグを抱えていましたが、WAPBL の重要な変更があったので幅広いテストが必要でした。だから、RC3 は正しかったと思っています。

In the end, deciding when to declare a release stable comes down to compromise. You have a hard list of requirements that the release must meet. Beyond that, you just have to get to a point where you feel that the remaining bugs are outweighed by all the positives in the new release. This is a hard thing to do, because when you've been tracking every problem raised for months, you tend to be focused on negatives and can easily forget about all the people who are having wonderful experiences. Eventually you have to let go and realize that you'll never have a bug-free release. When you get to that point, you tag the final release and hope that you haven't made a horrible mistake :)

最後に、stable をリリースするのに妥当な線を決定します。リリース必須項目を拝むことが出来ます。それから、新リリースにあるバグのうちいくつかの重要なバグを抱えたリリースを取得するだけです。毎月 何かしらの問題が発生していることがわかるので、これはしんどい作業です。悪い面に目がいくようになり、すべてのひとびとが *不思議な体験* をすることを簡単に忘れます。そして、バグなしのリリースが出来ることは無い、ということを悟るでしょう。そして、最後のリリースにタグをつけ、恐ろしいミスが無いことを祈りましょう :-)

NetBSDfr: As a conclusion, can you tell us how you imagine the future of NetBSD?

snj: We've made a massive jump with 5.0, and 6.0 should continue this trend. NetBSD has been ignored by many people for years, but this is changing. As for more specific predictions, I think we're going to see NetBSD usage increase greatly in the server and embedded worlds. I don't envision any radical shifts in direction, but this is not a problem. NetBSD has always been a great operating system; we just need to get out there and introduce more people to it.

NetBSDfr: 最後に、今後 NetBSD はどうなると思いますか？

snj: NetBSD 5.0 へ向けて大きく飛躍し、6.0 はその流れを汲んだものになるでしょう。NetBSD は何年も間 たくさんのひとびとから無視されてきましたが、これが変わります。もっと予言をすると、NetBSD はサーバーや組み込み機器でもっとたくさん使われるようになるでしょう。急激にそのようになっていくとは思っていないけど、それは問題ではありません。NetBSD はいつだって偉大なオペレーティングシステムです。もっとたくさんのひとびとに使ってもらうことだけが望みです。

Many thanks to Guillaume for his hard work on preparing, conducting and translating this interview and rendez-vous in a few weeks for the next one. I;n the meantime, any names of developers to interview, or questions you'd like to ask, are more than welcome.

Guillaume には作業の合間をぬってくれたことに感謝する。このインタビューは翻訳されて、数週間後に rendez-vous に置かれる。その間にインタビューしてもらいたい開発者の名前や、質問を送ってほしい。