Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ブランチ運用について #92

Closed
ashie opened this issue Oct 20, 2019 · 5 comments
Closed

ブランチ運用について #92

ashie opened this issue Oct 20, 2019 · 5 comments

Comments

@ashie
Copy link
Contributor

ashie commented Oct 20, 2019

webdino/meta-browserのブランチ運用について明確にしているドキュメントが無かったので、現状の説明をしておきます。と言っても何か明確な決まりがあるわけではなく、なんとなくこんな感じで運用していましたという説明です。特にこうしなければいけないとかでは無いので、今後の状況に合わせて変えてもらって良いと思います。

基本的な考え方や実際の状況

  • 可能ならばアップストリーム(OSSystems/meta-browser)をそのまま使う
    • 独自パッチを作成した場合は、mozilla-centralやOSSystems/meta-browserに還元してリリースされた版を使う
  • ただし、現実的にはどうしても独自ブランチを切る必要がある場合が多い
    • 各SoC向け安定版BSPに対して最新のGeckoを提供したい
    • SoCの安定版BSPはYocto/OEの少し古めのバージョンをベースとしている
    • OSSystems/meta-browserのmasterは1〜3バージョン前くらい前のYocto/OEしかサポートしない
  • OSSystems/meta-browserに先行して最新のGeckoのレシピを作成した場合は
    • OSSystems/meta-browserに還元してから独自ブランチを切ることを理想としていた
    • 実際にはwebdino/meta-browserで十分に枯らしてからフィードバックすることが多かった
    • 52esrや60esrはProject Quantumの影響でそもそもビルドを通すところでてこずることが多く、適切なタイミングでフィードバックできなかったため

ブランチの命名規則(のようなもの)

  • gem-firefox-${ver}esr
    • アップストリームに還元してから、それをベースに独自ブランチを切った場合のブランチ名
    • 実際にこの形式で運用できたのは以下のみ
      • gem-firefox-45.6.0esr
      • gem-firefox-45.9.0esr
  • firefox-${ver}esr
    • アップストリームに先行して最新のGeckoレシピを作成した場合のブランチ名
    • 結果的にこのブランチ名で運用することが多かった
    • minorバージョンが無い、majorバージョンのみのブランチが各ESRのメインブランチ
      • firefox-52esr
      • firefox-60esr
    • 上記のminorバージョン無しブランチのみであることが理想であるが(ESRのminorアップデートは基本的に適用すべき)実際にはminorバージョンアップも気軽にできない事情もあったので、minorバージョン付きブランチも存在している
  • firefox-${ver}esr-wip
    • 次期ESRリリース後なるべく早い次期にレシピを提供できるよう、アルファ段階から先行してキャッチアップして作業するためのブランチ
    • 最終的にコミットは全てSquash
    • アップストリームに還元するか、firefox-${ver}esrに移行
    • 基本的に削除しても良いブランチだが、試行錯誤の過程を確認できるよう、あえて残している
  • それ以外のOSSystems/meta-browserに無いブランチは、基本的に個別作業用のトピックブランチ
    • 基本的には作業を終えたら削除していっています
    • 今残っているものも、削除し忘れているだけで基本的にはほとんど削除してしまって良いものじゃないかと思います

68esrの状況について

  • wipとアップストリームにフィードバックしたもののみが存在し、独自ブランチ(gem-firefox-${ver}esrやfirefox-${ver}esr)はまだ切っていません
  • firefox-68-wipからアップストリームに還元する際に、Squashして更にOSSystemsの方でのやり取りを踏まえて変更したところがあったかと思いますが、その過程はfirefox-68-wipには残っていません
  • 68についてはリリース直後にOSSytemsに還元できたので、こちらをベースにしたブランチを切った方が良いのかな?と思っていました(OSSytemsの方で修正があった場合にバックポートしやすいかなという意味で)
  • あるいは、これまでの状況を見るとOSSystems側でそんなに頻繁に更新があるわけでもなさそうなので、完全に別のレシピに分けてしまった方が作業しやすいという考え方もあるかもしれません
@ashie
Copy link
Contributor Author

ashie commented Oct 20, 2019

あと、最新のGeckoを導入する上でブラウザ以外の周辺のライブラリに手を入れる必要がる場合は、meta-browserではなく、webdino/meta-gecko-embedded というレイヤを作ってそちらに入れていました。

こちらはブランチは切らない方針にして、必要に応じて(各BSPやそのバージョンに合わせて)、必要なレイヤを追加してもらう形にしていました。主にWaylandとGTKのバージョンを上げる必要がある環境のために用意したものですが、最近はその必要性も減っているので、ほとんど使っていません。

ただし、上記以外にもデモ用のレシピやデバッグ用のレシピなどもmeta-gecko-embeddedに入れてあるので、それらが必要なときには今でも使っています。

@ashie
Copy link
Contributor Author

ashie commented Oct 20, 2019

上記の説明のためだけに立てたissueなので、適宜Closeしてもらって大丈夫です。

@dynamis
Copy link
Contributor

dynamis commented Oct 21, 2019

ブランチ命名規則とステータスの整理、ありがとうございます。

Gecko 68 のコードについては firefox-68-wip よりも OSSystems/meta-browser の master の方が新しい状況なのですね。最近の修正を firefox-68-wip に入れてしまっていましたが、OSSystems/meta-browser の master から webdino/meta-browser/gem-firefox-68.X.Yesr にフォークして (または OSSystems 側に直接) 入れていかないとでしたね。

こちらの issue は後日 meta-browser の README か Wiki に説明を書き足すかプロジェクトサイト作って説明ページに書くか何かするときに閉じようかと思います。

@dynamis
Copy link
Contributor

dynamis commented Oct 21, 2019

ついでに書いておくと amethyst ブランチは最小限の XUL で起動する簡易 Web Viewer の開発コードを入れる想定で作ったブランチですが、諸都合により本日まで非公開リポジトリでの作業になっていたためブランチ切っただけで放置してしまったものなので削除します。

同じ Gecko 60, 68 などで webviewer アプリとしてビルドする為のレシピを追加するものなので (firefox_${ver}esr.bb と並列で nightly_${var}esr.bb を作っていたのと同様に)、ブランチ自体は別に分けることなく該当バージョンの独自ブランチ (gem-firefox-${ver}esrやfirefox-${ver}esr) にファイルを追加する形で追加します。

@dynamis
Copy link
Contributor

dynamis commented Mar 19, 2020

運用ルールは関係者で共有、それに合わせて進行できていると思うためクローズしますね。
変更時などはまた別途調整しましょう。

@dynamis dynamis closed this as completed Mar 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants