Antitrust Statement

All Linux Foundation (LF) activities are subject to compliance with the LF’s Antitrust Policy. Each individual participant and attendee at this meeting is responsible for complying with the LF Antitrust Policy. The LF Antitrust Policy is available at the URL link below or, if applicable, may be immediately emailed to anyone attending this meeting.

http://www.linuxfoundation.org/antitrust-policy

Participants of this meeting must NOT discuss:

  • The business strategy of any Member
  • Any attempts to restrict or hinder the growth or use of another industry standardization initiative
  • Actual, projected or future prices, or sales terms of their products
  • Marketing strategy, production capacity or release dates of their products
  • Allocation of customers or customer categories for their products

議事録

11:00 - 12:00

開催場所

Web Meeting

次回

 2021/3/25 11:00～12:00

参加者

課題の確認

Yuta Taguchi

  • 先週から進捗なし。
  • インテグ・実装に向けては、Pana小松(駒形さんのチーム)さんが推進する。

Masanori Maruyama

  • 不在のため明日確認

Naohiro Nishiguchi

  • ウォルトの問い合わせに対して、ジョージからはスケジュール通りとの回答

Naoto YAMAGUCHI

  • ICインテグ用のベース環境を引っ越し
  • DRMリースのレビュー
    • レビューに挙がっていたが、レビューアがいなかったので、山口・黒川・ジョージ(?)・JSをアサインしてもらった
      • 細川さんにも見てもらいたいので、お願いします。
    • ↑のホストへの組み込みは、マージされ次第開始予定
      • ゲストへの組み込みは、田口さんお願いします。
        • 具体的な方法は明日の議題にする。

Teppei Asaba

  • Bosch ICCOMMのインテグレーションを対応いただいている
    • ビルド確認中

明日のテックミーティングの議題整理

  • 日程感
    • スケジュールを作る
  • コンポーネントのリスト
  • 構造
    • DRMリースの組み込み(ホスト・ゲスト)
    • OSSコンポーネントの切り分け
      • Host/gest共通コアOSS (アセスメント対象)
      • 個別登載OSS(アセスメント対象)
      • デモ用
        • Host/Guestの具体的なリスト(manifest)
  • リポジトリへのコミット運用について
    • マージリクエストのやりかたとか
  • 課題の洗い出しをしたい


　HUDのプロファイル(?)について問い合わせが来ている。

  • 田口さんが内容を確認する。


開催場所

Web Meeting

次回

 2021/3/25 11:00～12:00

参加者

課題の確認

Yuta Taguchi

  • インテグの資料を解説
    • どこまでICEGでフォーカスするOSSにするのか？
      • hostとも共通になるコア、クラスタ共通、デモに分かれるはず。
    • 丸山さんとサービスの情報をシェアする

Masanori Maruyama

  • 資料の英語版を共有予定
  • ソースコードをどこにおくか？
    • githubにおいて共有する

Naohiro Nishiguchi

  • コラボラのウィークリーレポートを見る限り、何も動いていない。
    • ウォルトがすでにツッコミをいれているので、とりあえずまち

Naoto YAMAGUCHI

Teppei Asaba

  • Bosch ICCOMMのインテグレーションを対応いただいている
    • 今のリポジトリのままだとビルドが通らないことが分かったので、issueを投げて対応してもらった
    • 引き続き、ビルド確認中。

フューチャーリスト

  • Audioが来年も継続(～6月まで)
  • DRM Lease (メンテナンス、マイグレーション？)
  • DRM LeaseのV4L2オーバーレイ
  • Fast Boot
  • Linux-RTOS通信(Bosch iccom)のOSSリファレンス実装(LF メンターシップ)
  • IC インテレーションの別ボード対応(リファレンスハード/その他AGL公式サポート)
  • OSS assessment
  • ICの機能コンポーネントのようなもの？
  • バックアップDRAMけのRAMファイルシステム(たぶんPRでは出してない、これなPRものるかも)
    • と、それのICインテグへの適用
  • Bosch iccomのメンテナンス(agl-bspへマージ？)←Boschに確認してもらう
    • そういえば、名前変えないと。。

↑ 今晩のSATには、英語にして持っていく



11:00 - 12:00

開催場所

Web Meeting

次回

 2021/2/18 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 休みなので次回確認
  • 田口さんの問い合わせに関しては、コンポーネントの考え方はあっている。ただ、サービスとAPIが分かれているのは違うのでは？

Masanori Maruyama

  • 今週のアップデートなし
  • 3末のコードリリース予定になっているが、サンプルレべルのものは出せるかも
    • 来週のテックミーティングでレビューできるとよいのでは？

Naohiro Nishiguchi

  • AudioRFQ
    • 一応進んでいる。開発完了はワースト6末。

Naoto YAMAGUCHI

Teppei Asaba

  • 特になし。


ELISA workshopで発表した、ソース解析ツールの紹介スライド


11:00 - 12:00

開催場所

Web Meeting

次回

 2021/1/28 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • Clusterコンテナの設計中。まだフィードバックできるところまでは至っていない。
    • Clusterコンテナの中身は、コアOSS・リファレンスGUI・ICサービス・DRMリースつきのWestonを想定

Masanori Maruyama

  • ICサービスの実装を進めている。
    • 単体レベルのテストはほぼ完了。プロセスには準拠していない(日本語ドキュメントはある)。
    • 単体テストのクライテリアを見ているが、カバレッジを明確化したいがツールが課題になっていた(先週阿部さんから相談のあったもの)。
  • gcov(カバレッジ計測ツール)について
    • まだ使うところまではいっていないが、できそうという感触はあった。継続検討中。

Naohiro Nishiguchi

  • AudioRFQ
    • 一応進んでいる。開発完了はワースト6末。
    • ウォルトイシューは突破したので、とりあえず待ち。

Naoto YAMAGUCHI

Teppei Asaba

  • 特にアップデートはなし。



11:00 - 12:00

開催場所

Web Meeting

次回

 2021/1/28 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 欠席のため次週

Masataka Nagashima

  • 欠席のため次週

Naohiro Nishiguchi

  • AudioRFQ
    • SATでウォルトをフォローしたが、その後反応なし。

Naoto YAMAGUCHI

Teppei Asaba

  • kcovのアップデート(syzcaller)
    • 一部はとれるが。。という状況だったが、普通にとれるようになった。
      • 使っているラズパイが遅すぎて、カバレッジデータの収集が間に合わなかった模様。(ホストPCがタイムアウト)
      • ターゲットでカバレッジデータを吸い上げる部分ではとれているが、ホストへ送るところでタイムアウト
        • 高負荷試験で使えないってことはなさそう。

Abe Nozomu

  • ICサービスの実装を実装優先で実施中。いまのところ、プロセスへのフィードバックはなし。


ELISA WSの紹介

https://elisa.tech/workshop/2020/12/07/elisa-workshop-6-virtual-february-2-4/


AMMの発表について

丸山さんにしゃべってもらいたい。締め切りは今週金曜。

11:00 - 12:00

開催場所

Web Meeting

次回

 2021/1/14 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • お休みのため次週確認。

Masataka Nagashima

  • とくには課題なし。レビューも追加指摘はなかったので、実装に入る予定。
    •  テストの部分を最初に使うことになるので、フィードバックをお願いします。
  • IC-EG weekly callでのレビューに関して、検討をお願いします。

Naohiro Nishiguchi

  • AudioRFQ
    • SCで承認されたので、予算執行はできるはず。
    • Waltがちゃんと手続きをしたかは不明。。。次回のDevCall(1/5)に確認しましょう。

Naoto YAMAGUCHI

  • 共有できることは特になし。

Teppei Asaba

  • Syzcallerのトライを実施いただいている。kcovでカバレッジを取ることはできるようになった。ただ、なぜとれるようになったのかは不明。
    • gcovと使い方がだいぶ違うので、そのへんを見てみるとよいかも。

11:00 - 12:00

開催場所

Web Meeting

次回

 2020/12/10 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • お休みのため次週確認。

Masataka Nagashima

  • IPCの資料について
    • レビュー記録はどうしているのか？
      • 内部に閉じて記録、反映している。
      • 今後どうしていくかは、まだ考えていない。
    • プロセスのレビューやフォーマットの課題があればフィードバックをお願いします。
    • WebCallでのレビューについても考えてください
    • AGLコンフルエンスにツールが整備されているので、よかったら使ってください

Naohiro Nishiguchi

  • オーディオのRFQの修正は完了。SCでオーダはGoがけされたはず。。

Naoto YAMAGUCHI

  • 共有できることは特になし。

Teppei Asaba

  • 特に共有できることはなし。肝心のカバレッジがとれていない。設定を調査中。

その他

　　ELISA WS情報共有

11:00 - 12:00

開催場所

Web Meeting

次回

 2020/12/10 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • お休みのため次週確認。

Masataka Nagashima

  • Techi Mtgで、クラスターサービスのAPI提供メカニズムについて共有いただいている。
    • まだ、フィードバックすることは出てきていない。

Naohiro Nishiguchi

  • オーディオ以外は課題なし。

Naoto YAMAGUCHI

  • host(Container Manager)の開発に着手。課題共有予定。

Teppei Asaba

  • syzcallerにトライしている状況。makeはできて、ラズパイで挑戦中。


オーディオRFQレスポンスに対して、何をプロセスフォローしてもらうかを決めた。

Naohiro Nishiguchi 回答内容の資料添付お願いします


Container Hostのドキュメント作成で、テンプレートから変えた部分の共有と確認


11:00 - 12:00

開催場所

Web Meeting

次回

 2020/12/10 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 共有できるレベルの課題なし。

Masataka Nagashima

  • ティア1ミーティングの内容に基づいて、開発を進めている。
  • 共有するレベルの課題はいまのところない。

Naohiro Nishiguchi

  • 共有できるレベルの課題なし。

Naoto YAMAGUCHI

  • host(Container Manager)の開発に着手。ドキュメント書き始めたところ
  • dunfellベースにコンテナベース環境を移行して、ツール類を使えるようにする作業を実施中

Teppei Asaba

  • syzcallerのgithubのドキュメントを見たところ、実機でできそうだったので試そうとしたが、まだ動いていない。

  11:00 - 12:00

開催場所

Web Meeting

次回

2020/11/12 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 月曜日のティア1ミーティングで、中身をどう作っていくかについて議論を開始した
    • UIとコアスタックをPanasonic
    • サービスをNS
  • プロセスの試験運用含めて実施していく

Masataka Nagashima

  • 今後Cluster Container内部のアーキテクチャ、開発を田口さんたちと進めていく

Naohiro Nishiguchi

  • アップデートは特になし

Naoto YAMAGUCHI

  • host(Container Manager)の開発に着手。ドキュメント書き始めたところ
  • JS 新しいAGLレイヤアーキテクチャのレビューを実施
  • ALSのスケジュールを共有

Teppei Asaba

  • ELCで行われたSyzcallerを活用したテストに関して情報共有いただいた。 → 20201119_oss_eu_2020_collabora.pdf
    • 実ボードでの実施は行っていないよう

  11:00 - 12:00

開催場所

Web Meeting

次回

2020/11/12 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • とくにアップデート待ち
  • Cluster Containerのなかのアーキテクチャを確定させてから、要件～以降のプロセスを進める予定
  • ティア1ミーティング調整中

Masataka Nagashima

  • JSからの回答待ち
  • 今後Cluster Container内部のアーキテクチャ、開発を田口さんたちと進めていく

Naohiro Nishiguchi

  • 本日は不参加

Naoto YAMAGUCHI

  • SATレビューのステータスのアップデートを共有
  • host(Container Manager)の開発に着手。テックミーティングで要件について議論してまとめたところ。

Teppei Asaba

  • 特にアップデートなし


  11:00 - 11:40

開催場所

Web Meeting

次回

2020/11/12 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • プロセスのアップデートはとくに宿題なし。
  • Clusterティア1のなかで、スタックの要件を明らかにしてつくっていく活動を進めようと考えている。
    • クラスタティア1のミーティングで議論を始める

Masataka Nagashima

  • テストのところにJSがくれた助言について、回答を記載いただいた。JSからの返答はまだなし。

Naohiro Nishiguchi

  • 宿題なし。
  • トラックの仕組みについて、まち。
  • ウォルトのコメント待ち。

Naoto YAMAGUCHI

  • SATレビューのステータスのアップデートを共有
  • host(Container Manager)の開発に着手する予定。

Teppei Asaba

  • KCIDBの調査内容に


開催場所

Web Meeting

次回

2020/10/15 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 不在のため次回確認。ClusterContainerのスタック構築について話す。

Masataka Nagashima

  • 特になし。

Naohiro Nishiguchi

  • テンプレート・レビューの実験に取り組んでいただく。

Naoto YAMAGUCHI

  • ワークショップのドキュメントとフィードバックを共有

Teppei Asaba

  • 前回のカーネルCI関係の情報について、smatchをのケーススタディを説明頂いた。
    • カーネルビルドすると、コンソールログとして出力される。

  11:00 - 11:40

開催場所

Web Meeting

次回

2020/10/01 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 先週からのアップデートはなし

Masataka Nagashima

  • 先週からのアップデートはなし

Naohiro Nishiguchi

  • Architecture Design Template for the AGL development softwareのアップデートをいただいた、来週のレビューの発表資料に反映する

Naoto YAMAGUCHI

  • 先週からのアップデートはなし

Teppei Asaba

10月のバーチャルworkshopの資料作成で個別に問い合わせさせていただく可能性がありますので、その時はよろしくお願いします。

  11:00 - 11:40

開催場所

Web Meeting

次回

2020/10/01 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • テンプレートの修正を実施。

Masataka Nagashima

  • MemoryMapのところは、インストールのテストなのか、データの破損検知の話なのかで視点が変わるので、教えてほしい。
    • データの破損検知にフォーカスして記載を変更していただいた
      • やりかたとして、ツールを使ったテストとかでもいいのか？
        • テストプロシージャの話なので、そう書けばよい。

Naohiro Nishiguchi

  • 休みのため次回

Naoto YAMAGUCHI

  • 静的解析ツールの状況について
  • JSと1対1でミーティングを行った
    • 最初は、既存OSSにチェックをかけることに難色を示していたが、内容を説明してある程度納得してもらえた。

Teppei Asaba


10月のバーチャルworkshopの資料作成で個別に問い合わせさせていただく可能性がありますので、その時はよろしくお願いします。


  11:00 - 11:40

開催場所

Web Meeting

中止

  11:00 - 11:40

開催場所

Web Meeting

次回

2020/09/20 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

  • 静的解析ツールとの連携が必用、改めて説明

Masataka Nagashima

  • AGLで開発するほうのテストスペックのテンプレートを説明いただいた
  • MemoryMapのところは、インストールのテストなのか、データの破損検知の話なのかで視点が変わるので、教えてほしい。

Naohiro Nishiguchi

静的解析ツールの状況について

Naoto YAMAGUCHI

  • 静的解析ツールの状況について

Teppei Asaba

  • 　先週の資料はレッドマインにアップデートした。
    　疑問については、来週話す予定。

  • CIに関しては来週

  11:00 - 11:40

開催場所

Web Meeting

次回

2020/09/03 11:00～12:00

参加者

宿題の状況確認

Yuta Taguchi

Masanori Maruyama

  • 欠席

Naohiro Nishiguchi

Naoto YAMAGUCHI

  • 静的解析ツールの状況について

Teppei Asaba

  • 今日はアップデートなし　
  • まとめ資料を作成し次週(9/3)議論予定
  • CIAT環境について 
    • Kernel CIの紹介がELISAでもあった
      • IC EGとしてはUser space側へフォーカスでそのまま使える？
    • 最近Linux では いろんなToolが出てきており、カオスな状況
    • 今週のplumbersに出席
    • AGL CIATだけでカバーできないと思われる
    • ネタを考える

伊藤さん(OpenChain)

  • 欠席


2020/08/20 11:00～12:00

開催場所

Web Meeting

次回

2020/08/20 11:00～12:00

参加者

宿題の状況確認

田口さん

  • テンプレートの作成作業を開始した。Template for Detailed criteria of the reusing existing OSS。
  • 静的解析ツールのサマリの内容について
    • 静的解析ツールのレベル判定を進めているので(作成中のものがArch.のページの添付にこっそりついている)、それでレベルを決めて、件数ベースのリストを添付するイメージ

丸山さん

  • テストと検証の項目が混在していたので、テストの項目に関してテンプレート化している。検討中。

西口さん

  • ドキュメントは作成いただいているが、今日は不在のため次週確認。

山口

  • 既存OSSのアーキテクチャレベルのクライテリアのレビュー完了(Tech. MTG 8/18)
  • 静的解析ツールの状況について説明
  • 全体含めて、来週のAGL-SATでレビューして完了にする予定

浅羽さん

  • 今日はアップデートなし　

伊藤さん(OpenChain)

  • 浅羽さんから
    • SPDX3.0への提案は進んでいる。大きな動きはない
    • Usageプロファイルという形で、DownstreamからUpstreamへのものを提案しているが、いろんな意味で盛り上がっている。

次回

　8/27に開催する。


2020/08/6 11:00～12:00

開催場所

Web Meeting

次回

2020/08/20 11:00～12:00

  • SA tools
    • 改修必須のものとそうでないものを分類
    • AGL開発分について
      • 改修必須のものに対して改修させる or 改修しない理由を残す
    • 既存OSSについて
      • 参考程度に実行(？)し、結果レポートを提供
  • 既存OSSの再利用ケース(アーキテクチャレベル)
    •   Tech meetingに向けて対応中。レビュー予定。


2020/07/30 11:00～12:00

開催場所

Web Meeting

次回

2020/08/6 11:00～12:00

参加者

宿題の状況確認

田口さん

コンフルエンスには反映できていないが、再利用戦略のところをupdateして来週レビューする。

丸山さん

今週のアップデートなし。前回のSATレビューで方向性は固まった。

→ドキュメントのテンプレート作業に移行してほしい。

　テンプレートを元にブラッシュアップしたい。

西口さん

今日は不在のため次週確認。

山口

　　ドキュメントの更新の内容を説明。既存OSSの再利用ケース(アーキテクチャレベル)は、次のテックMTGでFixしたい。

　　静的解析ツールの分析をして、その結果から指標にするところまでやってテックMTGでレビュー。


浅羽さん

　林さんからJiraの課題管理とソース管理ツールの連携について説明いただいた。

　OpenSUSEの開発プロセスには、コードレビューについて記載されていなかった。コードはUpstreamから持ってくるものと言う位置づけと考えている。

　Atlassianが自社ツールの良さを主張している資料なので検証が必要だが、Redmine, github等と比較した結果を紹介いただいた。おかしい点もあるので、今後検証する。

　

　Yoctoのレシピに相当する、.specファイルはレビューのプロセスもない？

　→ない。メンテナーに依存している。MLでオープンになっているので、レビューされているという扱い。

　

伊藤さん

　SPDXに品質関連の追加投稿をした。反論があった場合に参戦してもらいたい。

　ELISAとオープンチェインの連携の件は、伊藤さん→ケイトでインプットしてもらう。


次回

　8/6に開催する。


2020/07/16 11:00～12:00

開催場所

Web Meeting

次回

2020/07/16 11:00～12:00

参加者

宿題の状況確認

田口さん

プロセスドラフトの作成に着手。
→OSSの再利用時の詳細なクライテリアを考え始めていて、8件挙げた。
D1は、変更点の確認。
D2は、バグトラッキングシステムのようなものがあるのか？
→デビアンのバグトラッキングシステムは、見るだけはできる。登録はメールで登録する。
　既存ディストリを参考にする。https://bugzilla.redhat.com/, https://www.debian.org/Bugs/

D4 コーディングルール適合
D5 からはどうしようかなと思っているところ。I/F仕様を見たほうが良いか。
→メジャーバージョンをセクション２、ABI互換がなくなっていないかどうかをチェックをセクション３にしてはどうか。
D6,D7は結合しないと見られないような。。。テストと相談したい。
→テストにもこの観点はある。再利用はテストでよいのでは。
D8は、リリースノートを作る。


丸山さん

テストクライテリアのたたき台を作成ていただいたので、内容をレビューした。
I3のところに、リソース関係を追加した
OSSのところはインテグレーションのみにして、Unit Testを外した。


西口さん

Architecture Design for the AGL development softwareのアップデート内容について説明いただいた。


山口

　　J.S.が推薦してくれた、clangベースの静的解析ツールとほかの静的解析ツールを解析した結果の共有を行った。

　　glibcやsystemdをサンプルとしたが、解析した結果抽出された問題個所がほとんど一致しない問題があり、結果とコードを見比べながらサンプル調査を行った。

　　その結果、どちらもツールの限界で発生する誤検出が違う場所が出ていることが原因で、本当に問題のある個所ではないものだった(サンプル20件)。

　　いったん、J.S.推薦ツールで進めてしまってよいのではないかと考えている。


浅羽さん

　オープンチェインで、SPDXのフォーマットにルールの所在といった情報を追加する提案をした。
　JapanとWWの両方で話をして、ケイトはポジティブな反応を示してくれた。


　ETVXで現在のプロセスを評価する取り組みについて、現状を説明いただいた。

　　ETVXでプロセスを評価するのは効果があると考えており、推奨する。

　　ツールが重要。OpenSUSEとAGLは違うものを使っているが、jirraを有効活用するとよいと考えている。

　　→Jirraに関しては、AGL SPECの1つを事例として、J.S.がサンプルを作ってくれるので、それを元に次回可能であれば議論したい。
　

　　ツールの連携が大事。JiraはIssuとレビューが連携できる。トレース・トラックを見てもらえるとありがたい

次回

　7/23は世間はお休みなのでジャンプし、7/30に開催する

2020/07/9 11:00～12:00

開催場所

Web Meeting

次回

2020/07/16 11:00～12:00

参加者

宿題の状況確認

田口さん

プロセスドラフトの作成に着手。今週進める予定。


丸山さん

テストクライテリアのたたき台を作成ていただいたので、内容をレビューした。

SWE6に関しては、ディストリビューション全体のテストなので、既存OSSとAGL開発の区別はいらないと考えている。


西口さん

開発のエントリクライテリアを書けばよいかなと思っている。

利用する側に関しては、以前議論した内容で良いと思っている。


山口

　　プロセスのドラフトを作成中

　　OSSクライテリアはSPDXに情報をいれるといい、ルネサス伊藤さんに頼む。


浅羽さん

　　ディストリビューションのクライテリア・プロセスを引き続き調査する

      →ETVXがベースになっているので、今作っているプロセスがこれに合致しているかどうかを監査するとよい。

　　→その作業工程をどこかでやるようにする。


2020/07/3 11:00～12:00

開催場所

Web Meeting

次回

2020/07/16 11:00～12:00

参加者

宿題の状況確認

田口さん

コーディングルールの対象の範囲をOSSまでみるのか、自社開発だけなのか確認する(次回のアンケート)

     6/18までに案を作成してこの場でレビューする。6月末に集約くらいの日程感。

     →　アンケート内容を確認

　　　OpenSUSEのプロセスに関しては、これを受け入れようと思った場合に何が足らないかを聞く

　　　再利用戦略については追加は必要ないか？

　　　→SUSEのプロセスにテストの項目があるので、OpenSUSEのアンケートだけでよい。

　　→明日期限で集約中。


丸山さん

今回のアンケート結果から、ブラックボックステストが重要とわかったので、検討いただく。

OpenSUSEのテストの仕組みや内容を確認・評価する。


調査をした。テストの内容はブリーフテストのように見える。

→SUSEはディストリビュータなので、個々のパッケージはコミュニティに任せるよにしている


アンケートでテストの要求スペックを確認する



西口さん

AGLで開発するもの(例: drm lease)に対しては、実装に入るための基準を決めないといけない。

AGL外でつくられたものをAGLからリリースする場合はSWE.3は適用できないと考えるので、再利用戦略でカバーするしかないと考えている(REU.2)

→再利用のときはブラックボックステストにしたい。

　ブラックボックステストを作るときの、requirementのカバレッジの%を決める必用があると考えている。

　→継続検討

 


山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　OpenSUSEのプロセスが使えそう

　　https://en.opensuse.org/openSUSE:Development_Process_Details

　　→各社のアセッサにASPICEとの適合度をみてもらえないか確認してもらう

　　→田口さんのアンケートで、このプロセスで開発されたAGLディストリビューションを実際に採用する場合に、どこに問題があるとるか聞いてもらう       


      プロセスのドラフトを作成中

      →　JS, Scott, Waltも参加した、AGLの活動にステップアップ

　　    谷川さんにも協力してもらい、開発は既存のAGLツリーとは分けて、干渉しないようにして行う事をJSと合意。去年の9月のF2Fからあった課題が一つ解決した。

　　　しばらくは、毎週月曜のJST PM10:00～11:00で検討することになる。

　 ドラフト本文はJSのGoogleDocに移動。その他文章は、元のコンフルのまま。

　　　OSSクライテリアはSPDXに情報をいれるといい、ルネサス伊藤さんに頼む。


浅羽さん

　　ディストリビューションのクライテリア・プロセスを引き続き調査する

      →今日はなし


https://elinux.org/Japan_Technical_Jamboree_73


2020/06/25 11:00～12:00

開催場所

Web Meeting

次回

2020/06/25 11:00～12:00

参加者

議事

2020/06/18 11:00～12:00

開催場所

Web Meeting

次回

2020/06/25 11:00～12:00

参加者

議事

宿題の状況確認

田口さん

コーディングルールの対象の範囲をOSSまでみるのか、自社開発だけなのか確認する(次回のアンケート)

     6/18までに案を作成してこの場でレビューする。6月末に集約くらいの日程感。

     →　アンケート内容を確認

　　　OpenSUSEのプロセスに関しては、これを受け入れようと思った場合に何が足らないかを聞く

　　　再利用戦略については追加は必要ないか？

　　　→SUSEのプロセスにテストの項目があるので、OpenSUSEのアンケートだけでよい。


丸山さん

今回のアンケート結果から、ブラックボックステストが重要とわかったので、検討いただく。

エビデンスを作るアプローチに対しては、そのもととなる解析に、シノプシスのコベリティのOSSスキャンがつかえるかどうか確認いただく。

→　コベリティのスキャンを確認した

　　有効かどうか、という意味では有効だと思う。ただ、例に挙げたwestonのエラーは、受け入れとして厳しい結果になっていた。

　　再利用戦略に絡むと思う。外部OSSの品質保証をどうするのか？だと考えている。ブラックボックステストベースでの保障になると思う。

次のアイテムとして、OpenSUSEのテストの仕組みや内容を確認・評価する。


西口さん

AGLで開発するもの(例: drm lease)に対しては、実装に入るための基準を決めないといけない。

AGL外でつくられたものをAGLからリリースする場合はSWE.3は適用できないと考えるので、再利用戦略でカバーするしかないと考えている(REU.2)

→再利用のときはブラックボックステストにしたい。

　ブラックボックステストを作るときの、requirementのカバレッジの%を決める必用があると考えている。

　→継続検討


山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　OpenSUSEのプロセスが使えそう

　　https://en.opensuse.org/openSUSE:Development_Process_Details

　　→各社のアセッサにASPICEとの適合度をみてもらえないか確認してもらう

　　→田口さんのアンケートで、このプロセスで開発されたAGLディストリビューションを実際に採用する場合に、どこに問題があるとるか聞いてもらう       


      プロセスのドラフトを作成中



浅羽さん

　　ディストリビューションのクライテリア・プロセスを引き続き調査する


　　パッケージ選定プロセスの具体例を提示いただく。

　　　コンテナとXMLやJSONパーサのような、同じ機能のものがたくさんある事例にする。

　　　→判定基準を説明いただいた。資料は別途共有。

2020/06/11 11:00～12:00

開催場所

Web Meeting

次回

2020/06/18 11:00～12:00

参加者

議事

宿題の状況確認

田口さん

コーディングルールの対象の範囲をOSSまでみるのか、自社開発だけなのか確認する(次回のアンケート)

アンケートの募集をします。

→　1. コーディングルールの対象の範囲をOSSまでみるのか、自社開発だけなのか確認する

       2. OpenSUSEのプロセスについて、受け入れられますか？何が足らないか教えてもらえませんか？

　　3. SWE3の達成条件の回答がわからない、という回答になってしまったので、具体的に聞けるように項目を作る

　　

     6/18までに案を作成してこの場でレビューする。6月末に集約くらいの日程感。

　　 期間がないので、次回確認ではなく、随時田口さんにメールでききたい内容を送付する。


丸山さん

今回のアンケート結果から、ブラックボックステストが重要とわかったので、検討いただく。

エビデンスを作るアプローチに対しては、そのもととなる解析に、シノプシスのコベリティのOSSスキャンがつかえるかどうか確認いただく。

→次週確認


西口さん

AGLで開発するもの(例: drm lease)に対しては、実装に入るための基準を決めないといけない。

AGL外でつくられたものをAGLからリリースする場合はSWE.3は適用できないと考えるので、再利用戦略でカバーするしかないと考えている(REU.2)

→次週確認


山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　OpenSUSEのプロセスが使えそう

　　https://en.opensuse.org/openSUSE:Development_Process_Details

　　→各社のアセッサにASPICEとの適合度をみてもらえないか確認してもらう

　　→田口さんのアンケートで、このプロセスで開発されたAGLディストリビューションを実際に採用する場合に、どこに問題がるか聞いてもらう       


　　OpenSUSEは、LTS期間が短いためコードベースとしては課題がある。

　　　以前Debianを検討していたが、古いソースコードがリポジトリから消されてしまうなど、課題が多かった。それでRedHatとかも見ているのが現状。

　　　Yocto LTSは、レシピのメンテナンスまではするが、コードのメンテナンスをするわけではないので、コードベースの問題は解決できないのではと考えている。


浅羽さん

　　ディストリビューションのクライテリア・プロセスを引き続き調査する

　　→次週確認

　　パッケージ選定プロセスの具体例を提示いただく。

　　　コンテナとXMLやJSONパーサのような、同じ機能のものがたくさんある事例にする。

2020/06/04 11:00～12:00

開催場所

Web Meeting

次回

2020/06/11 11:00～12:00

参加者

議事

宿題の状況確認

田口さん

コーディングルールの対象の範囲をOSSまでみるのか、自社開発だけなのか確認する(次回のアンケート)

アンケートの募集をします。

→次週持ち寄る


丸山さん

今回のアンケート結果から、ブラックボックステストが重要とわかったので、検討いただく。

エビデンスを作るアプローチに対しては、そのもととなる解析に、シノプシスのコベリティのOSSスキャンがつかえるかどうか確認いただく。

→次週確認


西口さん

AGLで開発するもの(例: drm lease)に対しては、実装に入るための基準を決めないといけない。

AGL外でつくられたものをAGLからリリースする場合はSWE.3は適用できないと考えるので、再利用戦略でカバーするしかないと考えている(REU.2)

→次週確認


山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。


浅羽さん

　　商用・オープンディストリビューションのクライテリアをまとめていただく。

　　ディストリビュータのテストは、インストール・アンインストールをテスト観点にしている。

林さん

　　Fedraはテストケースを公開しているが、対象環境に自動的にインストールして起動するかどうかを確認するにとどまっている。

　　Fedraのリリースクライテリアは、Webで公開されている。

　　OpenSUSEは、OBSでビルドしたものをopenQAというtoolを使ってテストを行っている。

　　Debianは，役割に関するルールがしっかりしている。






SATでの議論の開始について

　アンケートの結果と、今のこの活動の内容を5/28のSATで枠をとって議論する。

　→資料は次回レビュー


商用ディストリビューションの紹介(上羽さん)

　富士通コンピュータテクノロジでは、富士通向けのシスとリビューションの開発を20年ほど行ってきた。    
　現在は、Yoctoベースのディストリビューションで、Upstreamすることで品質確保する方向で活動している。
　基本は最新リリースに製品が追従してくれるのが良いと考えている。



議事録

2020/05/28 11:00～12:00

開催場所

Web Meeting

次回

2020/05/21 11:00～12:00

参加者

議事

新しい参加者

　浅羽さん、上羽さん、信田さんが新規に参加いただけることになりました。

宿題の状況確認

田口さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

アンケート結果について説明いただいた。


4番の静的解析ツールの結果に対して、問題のない事をエビデンスつけているが、OSSにもやっているのか？

やらずにできるのか疑問、上のアンケートの結果からすると、やっているのでは？


ここで出てくるOSSの中身はわかるか？Linuxレベルなのか？それとも計算ライブラリの一部なのか？

→アンケートでは、ライブラリやミドルウェアという聞き方をしている。

　メータなので、システム規模が小さいため利用も限られていると思う。


丸山さん

丸山さんの活動として、QMレベル対応を前提とした場合にOSSに対して必要以上のルールの要求がされていないかを確認してもらう。

→テストスペックの方針としてMISRAへの順守を考えていたが、利用するOSSに要求するのは無理。エビデンスを残すような方向性しかない。

 今回のアンケート結果から、ブラックボックステストが重要とわかったので、検討いただく。

エビデンスを作るアプローチに対しては、そのもととなる解析に、シノプシスのコベリティのOSSスキャンがつかえるかどうか確認いただく。


西口さん

SWE.3について、アセッサの見解を集約する。

→ 考えていただいた案のアンケート結果にギャップがあるため検討が必要

AGLで開発するもの(例: drm lease)に対しては、実装に入るための基準を決めないといけない。

→これをかんがえないといけない。(案を作成する 西口さん)

AGL外でつくられたものをAGLからリリースする場合はSWE.3は適用できないと考えるので、再利用戦略でカバーするしかないと考えている(REU.2)


山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　(富士通さんから)　商用・オープンディストリビューションのクライテリアをまとめていただいている。

　　　ディストリビュータはパッケージングを主体にしていて、品質基準を設けていない場合が多い。

　　　組み合わせ検証は、ある程度やっている。


SATでの議論の開始について

　アンケートの結果と、今のこの活動の内容を5/28のSATで枠をとって議論する。

　→資料は次回レビュー


2020/05/21 11:00～12:00

開催場所

Web Meeting

次回

2020/05/21 11:00～12:00

参加者

議事

宿題の状況確認

田口さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

→5/22締め切りで集約中。回答が全て集まっていないのでフォロー中。明日の段階で結果をアップロード予定。


丸山さん

丸山さんの活動として、QMレベル対応を前提とした場合にOSSに対して必要以上のルールの要求がされていないかを確認してもらう。

→社内でも議論がまとまらず、各社の見解を聞きたいということになった。

　→田口さんのアンケートに追加して、各社の見解を集める。

       →田口さん待ち


西口さん

SWE.3について、アセッサの見解を集約する。

→ 不在のため次週確認

　→まだ回答をもらえていない。

　　→ 不在のため次週確認

山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　→RedHatは原木さんにQAをお願いする

　　　apertisはBoschさんが質問を受けてくれると言っていたので、原案を作成しました。

　　　→現状待ちになっているので、ドキュメントテンプレートを探す活動を行っている。学会の発表や、規格の付録などを見ているが、まだ良いものは見つかっていない。

　　　　もし、どこかで事例の話があれば教えてほしい

　　　　IPAがやっていないか？(西口さん)


来週ELISAのワークショップの共有(プロセス・テスト関係)を行う(少なくとも、山口、西口さん、原木さんは参加する)

Collaborate Virtually at ELISA May Workshop - ELISA

The ELISA community will be collaborating virtually for the May Workshop on May 18-20. Over twenty sessions with focus ranging from new community member orientation…


SATでの議論の開始について

　アンケートの結果と、今のこの活動の内容を5/28のSATで枠をとって議論する。

コンパイラについて

　コンパイラで困っていることはないか？　

　　機能安全認証をgccで取ろうとすると、ものすごい手間がかかって困る。

　　　****の場合、セーフティに影響を与えるツール(コンパイラ等)が認証されていなくても、後工程でカバーすることは可能とアセッサに聞いた。(コードカバレッジを確保したテストなど)

IC-EGのゴールの明確化に関して

　次回、タスク間の順序関係のまとめをこの場でやる。




2020/05/14 11:00～12:00

開催場所

Web Meeting

次回

2020/05/21 11:00～12:00

参加者

議事

宿題の状況確認

田口さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

→issue更新済み

　アンケート案を共有(TODO:田口さんリンク追加お願いします)

　丸山さんから、コーディングルールに関する質問の追加要望があった


丸山さん

丸山さんの活動として、QMレベル対応を前提とした場合にOSSに対して必要以上のルールの要求がされていないかを確認してもらう。

→社内でも議論がまとまらず、各社の見解を聞きたいということになった。

　→田口さんのアンケートに追加して、各社の見解を集める。

       →田口さん待ち

西口さん

SWE.3について、アセッサの見解を集約する。

→ 不在のため次週確認

　→まだ回答をもらえていない。

山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　→RedHatは原木さんにQAをお願いする

　　　apertisはBoschさんが質問を受けてくれると言っていたので、原案を作成しました。

　　　→現状待ちになっているので、ドキュメントテンプレートを探す活動を行っている。学会の発表や、規格の付録などを見ているが、まだ良いものは見つかっていない。

　　　　もし、どこかで事例の話があれば教えてほしい

　　　　IPAがやっていないか？(西口さん)


来週ELISAのワークショップの共有(プロセス・テスト関係)を行う(少なくとも、山口、西口さん、原木さんは参加する)

Collaborate Virtually at ELISA May Workshop - ELISA

The ELISA community will be collaborating virtually for the May Workshop on May 18-20. Over twenty sessions with focus ranging from new community member orientation…


SATでの議論の開始について

　アンケートの結果と、今のこの活動の内容を5/28のSATで枠をとって議論する。

コンパイラについて

　コンパイラで困っていることはないか？　

　　機能安全認証をgccで取ろうとすると、ものすごい手間がかかって困る。

　　　****の場合、セーフティに影響を与えるツール(コンパイラ等)が認証されていなくても、後工程でカバーすることは可能とアセッサに聞いた。(コードカバレッジを確保したテストなど)

IC-EGのゴールの明確化に関して

　次回、タスク間の順序関係のまとめをこの場でやる。


2020/04/30 11:00～12:00

開催場所

Web Meeting

次回

2020/05/14 11:00～12:00

参加者

議事

宿題の状況確認

田口さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

→issue更新済み

　アンケート案を共有(TODO:田口さんリンク追加お願いします)

　丸山さんから、コーディングルールに関する質問の追加要望があった

丸山さん

丸山さんの活動として、QMレベル対応を前提とした場合にOSSに対して必要以上のルールの要求がされていないかを確認してもらう。

→社内でも議論がまとまらず、各社の見解を聞きたいということになった。

　→田口さんのアンケートに追加して、各社の見解を集める。

西口さん

SWE.3について、アセッサの見解を集約する。

→ 不在のため次週確認

山口

　　既存のディストリビューションの組み合わせ検証プロセスを調査する。

　　→RedHatは原木さんにQAをお願いする

　　　apertisはBoschさんが質問を受けてくれると言っていたので、原案を作成しました。


5月のELISA WSに関して

　　QMの観点でいくつか興味深いものがあるので紹介

Linux Kernelを「安全」なものにするための、.configの設定について

https://lists.elisa.tech/g/devel/topic/may_workshop_proposal_safe/73323841?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,73323841

- Topic idea

  • Safe Linux features (.config settings)

- What you hope to accomplished in the session

  • Present a list of kernel configs (fundamental features) which are relevant for FFI/memory protection as defined by ISO26262/IEC61508.
  • Discuss the advantages and potential pitfalls of each.
  • Open discussion on which of those features seem to be most relevant as safety features, and what would be needed to qualify those settings for use as safety mechanisms
stress-ngについて(カーネルのテスト手段として)

https://lists.elisa.tech/g/devel/topic/may_workshop_proposal/73156864?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,73156864

- Topic idea: 

  • stress-ng for kernel testing

- What you hope to accomplished in the session:

  • Overview by Colin King of stress-ng
  • Overview of Mobileye stressors and test plans
  • Call for additional contributors

参考URL(このトピックが挙がった時に紹介されたもの)

https://kernel.ubuntu.com/~cking/kernel-coverage/stress-ng/stress-ng-0.11.07/


IC-EGのゴールの明確化に関して

　　全体の関係性を整理したい。

　　原木さんがたたきを作成する。

　　→月曜日のEGで共有。タスク間の依存関係(Aが終わらないとBが着手できない、Cが終わらないとDが着手できない)を確認したい。

　　　山口がたたきを作成する。田口さん、クラスタコンテナについて質問すると思うのでお願いします。

2020/04/23 11:00～12:00

開催場所

Web Meeting

参加者

議事

宿題の状況確認

田口さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

田口さんから、ヒアリング内容について説明。レビュー中で修正予定があるため、今週中にupdateした資料をメンバーに送付予定。

　　双方向トレーサビリティについてどう扱えばよいか悩んでいる。OSSは対象として考えていない。

　　西口さんの先週の議論の内容を確認。

　　双方向トレーサビリティは必要ないと考えているが、各社が同じかヒアリングしてほしい。(山口)

次回、アンケートの状況を確認する。

丸山さん

丸山さんの活動として、QMレベル対応を前提とした場合にOSSに対して必要以上のルールの要求がされていないかを確認してもらう。

→来週確認

西口さん

SWE.3について、アセッサの見解を集約する。

→コロナでレスポンスが悪く、今週は進捗なし。

山口

　　既存のディストリビューションのの組み合わせ検証プロセスを調査する。

　　→Apertisに関して調査したが、QAのテストケースはAGLでも行っているような、ディストリビューションのユースケースレベルだった。

　　　これ以外に、コンポーネントのテストケースがあったが、数が少ない。Debianベースという話だったが、QAでどう関係しているのかはわからなかった。

IC-EGのゴールの明確化に関して

　　全体の関係性を整理したい。

　　原木さんがたたきを作成する。

2020/04/16 11:00～12:00

開催場所

Web Meeting

参加者

議事

宿題の状況確認

田口さん、駒形さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

来週、ヒアリング内容を共有予定

丸山さん

コーディングルールに関しては、決めたものをすべて満たすのではなく、正当な逸脱理由をエビデンスとして残す事が必用。
既存のOSSのコーディングルールと、自社のコーディングルールが矛盾する場合でも、なぜそうなっているのかがはっきりすればよい。

既存のOSSに対して、逸脱していても良いというエビデンスを残す必要があるのか？(西口さん)

過去に、OSSに対して逸脱エビデンスを残す活動をしたことがあるが、ものすごく大変だった。(丸山さん)

その大変なエビデンスを残す活動をIC-EGでやるのは難しいと思う。Lintというツールでチェックすることができるが、自分たちが書いたコードが限界。
AGLで開発する部分に対して行うのが限界では。(西口さん)

外部のOSSを持ってくるケースが問題なのは同意(丸山さん)

コーディングルールどうしを比較して、包括的に認めることはできないか？(山口)

今回見たカーネルやGNUのコーディングスタイルは、安全性に関わる部分は書かれていない。たとえば、動的メモリなど。包括的でも難しいのでは？(丸山さん)

動的メモリに関しては、例えばISO26262ではASIL-Aでは推奨でしかなくて、ASIL-Bから必須になっている。機能安全対応を意識して、QMに対する要求レベルを上げているのではないか？(山口)

丸山さんの活動として、QMレベル対応を前提とした場合にOSSに対して必要以上のルールの要求がされていないかを確認してもらう。

JSに、ツール系をAGLインフラに入れることができるか確認してみる。


西口さん

今回時間の関係で話せなかったSWE.3について、ASPICEのドキュメントファーストとOSSのコードファーストが相反しているので、どういう理論建てをすればこの矛盾を解消できるのかを考える。

西口さんがアセッサに確認したところ、

1)詳細設計プロセスで、ソースコードの関数名、I/F定義、関数呼び出し関係を定義
2)これに基づいて実装プロセスでソースコードを実装。

がそろっていれば、通すことができると言っていた。

各ティア1がどう考えているかはぜひ知りたい。

　　　→田口さんが取り組むアンケートきいてもらう事になっているので、来週ヒアリング内容を確認する。

山口

SWE.2について、issue「OSSの組み合わせに関する課題」を追加した。Redhat、Debianなどの検証プロセスを流用(コードごとできるならコードごと)できないから、調べたい。誰か、検証プロセスを知っている人がいればお願いしたい。

XXXXのXXXXというディストリビューションがあるので、その検証プロセスを調べてはどうか？(西口さん)

IC-EGのゴールの明確化に関して

各社の考えを集約した結果について説明。

2020/04/09 11:00～12:00

開催場所

Web Meeting

参加者

議事

宿題の状況確認

田口さん、駒形さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

→このタスクに関して、何を聞くかを具体化したいという話が先週のメールのやりとりであった。IC-EG Redmineで課題をissue化したので、ここで議論を進める。

   ヒアリング内容は、issue参照。

丸山さん

コーディングルールに関して、Linux KernelとGNUに対してギャップ分析を行う。

→今週は不在のため来週確認。

西口さん

今回時間の関係で話せなかったSWE.3について、ASPICEのドキュメントファーストとOSSのコードファーストが相反しているので、どういう理論建てをすればこの矛盾を解消できるのかを考える。

　　→今週は不在だが、issueに検討内容を記載してくれたのでその内容を、参加者で確認・議論

　　　課題

1.詳細設計プロセス->実装プロセスを実装プロセスの中で詳細設計をやっていると述べてA-SPICE Lv.2等に耐えれるのか
2.詳細設計書はDoxy、Markdownで問題ないと思われるが内容(関数名、I/F定義、関数呼び出し関係)をAGLとしてルール化するか(受け入れてもらえるか)
3.双方向トレーサビリティの確立をどのように行うか。

　　　西口さんがあげてくれた課題について、AGLコミュニティが開発するケース(ファンドなど)と既存のOSSを持ってくる場合で分けて考える必要がある。

　　　とらないといけないアクションは2つ、

　　　　AGLコミュニティに必要性を広く訴えて、受け入れてもらう&落としどころを見つける

　　　　既存OSSに関しては、既にあるものを選んで使うので、双方向トレーサビリティはいらないのではないか？ドキュメントと実装の一致を確認できればよいのでは？

　　　　→田口さんのアンケートで、メータティア1がすでにASPICEの下でOSSを使っていることがわかっている。次のアンケートで、この点をどう解決しているのかをきいてもらう。(Issueに追記)

山口

ドキュメントの指摘事項のアップデート

　　 →SWE.1, SWE.2に関して、指摘事項をどうアップデートしたのかを説明。

　　　今後、参加メンバーにも提案資料を修正してもらう必要があるが、今の共有方法ではやりづらい。

　　　→ IssueがSWEごとにわかれているので、その階層にSWE単位で分割した形で添付ファイルとして資料を置き、それをどんどん更新する事にする。一定のタイミングで資料を統合し、AGLのコンフルエンスで公開する。

IC-EGのゴールの明確化に関して

現在タスクを分割して、各社にかつどうしてもらっているが、最終的なゴールが見えるようになっていない。見えるようにしたい。取り組みの範囲は、クラスターとホスト。(原木さん)

メンバーはこのプロセスワーキングのメンバーと同じなので、プロセスワーキングの時間の枠で議論する。


2020/04/02 11:00～12:00

開催場所

Web Meeting

参加者

田口さん(Panasonic)、駒形さん(Panasonic)、丸山さん(日本精機)、西口さん(ADIT)、原木さん(スズキ)、山口(AISIN-AW)(議事)

議事

サブワーキングの趣旨と目的の共有

Container managerの開発に着手するにあたり、AGLの品質基準がない(設計ルール、ドキュメントルール、コーディングルールなどがない)という課題が見えてきたた。同じ課題に直面するQMタスク、テストスペックタスク、ファンディング予定のタスクと協力して、この課題を解消したい。


進め方について

ASPICEを参照して、SWE/ACQで示される基準をOSSどうやって満たしていくかを考えて、AGLの品質基準にしたい。対象は、ClusterとContainer hostに含まれる、AGL開発成果物と外部からもってきたOSSを対象としたい。


現在の検討状況の共有

SWE.1に関しては、基本的にはIndustry(AGLを製品で使おうとする人たち)が製品仕様のどの部分をAGLを使って実現できるのかを決める段階なので、BPをAGLコミュニティが満たす必要はないと考えている。

Industryは、AGLコミュニティをサプライヤ監視(ACQ.4)を使って、認証(Certify)し信じる(Trust)事になる。しかし、AGLはオープンソースコミュニティなので、サプライヤではないことに注意する必要がある。また、ICEGは、Industryのメンバーであると同時にAGLコミュニティのメンバーでもあるという点に着目する。

これらの前提に立つと、IC-EGのメンバーは、サプライヤとカスタマーの意思統一、情報共有といったBPについてはすでに満たしていると考えることができる。その場合、ACQ.4で求められる成果物に関しては、Commitment/agreementとReview recordが用意できれば良いのではないか？

ACQ.4.

02-01

Commitment/agreement

13-01

Acceptance record

13-04

Communication record

13-09

Meeting support record

13-14

Progress status record

13-16

Change request

13-19

Review record

14-02

Corrective action register

15-01

Analysis report

Change requestとAnalysis reportは必要ではないか？(丸山さん)

AGLコミュニティは、AS ISでソフトウェアを提供するので、IndustryからChange requestを発行する事はない(やってはいけない、要望であればよい)のではないか？コードのバグとかであればあるかもしれないが。。。(山口)

Change requestは、カスタマーから出す場合もあるが、サプライヤから出す場合もある。こちらのケースは存在すると思う(西口さん)

確かに指摘の通りなので、Change requestとAnalysis reportも必要と、ドキュメントに追加する(山口)

Commitment/agreementをAGLが示すために、AGLで何ができるのかを示すリファレンススペック、AGLのルール(少なくとも、コントリビューション、デザイン、コーディング、ドキュメンテーション)、レビュー記録が必用と考えている。

今のAGLはコントリビューションルールだけ存在すると言っていたが、具体的にどれか教えてほしい(田口さん)

AGLのwikiにあるので見てほしい(山口)　https://wiki.automotivelinux.org/agl-distro/contributing

各ルールは具体的にどのようなものか？(原木さん)

デザインルールはソフトウェアの設計ルール、ドキュメンテーションルールはその設計をどうドキュメントとして書くか(例えば、UMLで書くとか)、コーディングルールは実際にコーディングするときの書き方(例えばMISRA)を指している。実際にどうするかはこのWGで議論したい。(山口)

議事録のルールも必要ではないか？(丸山さん)

確かにその通り、追加する(山口)


SWE.2では、要件をAGLがコミュニティ内で開発するものと、他のプロジェクトからOSSを持ってくるものに分解する。

コミュニティでは、決められたルールに従ってBPを満たしていけばよいが、BP5(リソース消費目標)に関しては困難と考えている。そのため、AGLコミュニティはBP5に関してはリファレンス環境でこれを達成し(これは原木さんがICEG設立当初から挙げているやらないといけないことと同じ)、最終製品でどうなるかはIndustryが行うという考え方をする。

SWE.2.

BP1

Develop software architectural design.

BP2

Allocate software requirements.

BP3

Define interfaces of software elements.

BP4

Describe dynamic behavior.

BP5

Define resource consumption objectives.

BP6

Evaluate alternative software architectures.

BP7

Establish bidirectional traceability.

BP8

Ensure consistency.

BP9

Communicate agreed software architectural design.


成果物に関しては、AGLコミュニティが開発する部分に関してはSWE.1のところで述べたルールに従って開発を行うことで、作ることができると考えている。

外部のOSSプロジェクトからもってくるものに関しては、AGLコミュニティで決めたルールを守っていると認められる(Certify)かどうかをチェックし、認めることができるもののみを採用するような考え方を考えている。この方法論は、ELISA/SIL2Linuxでも同じような研究がされているし、先行研究(1,2)もあるため、これらを参考にやりかたを決めていきたい。

SWE.2

04-04

Software architectural design

13-04

Communication record

13-19

Review record

13-22

Traceability record

17-08

Interface requirement specification

これらは、REU.2「再利用プログラムの管理」にあるBP1「再利用戦略の定義」をAGLで行った上でOSSを使うということだと思う。(西口さん)

実は、ここまでやったとしてもASPICEのLv1を達成することしかできない。実際にはどのくらいのレベルを要求されるのか？(山口)

ASPICEのLv2か3が多い(田口さん)

最初はLv1しかできないが、それでもこの取り組みに意味がある？(山口)

いきなりLv2や3を狙うよりも段階的にやったほうが良い。これができれば、シンポジウムで発表できるレベル。(西口さん)

まずはLv1に取り組むことで合意(参加者全員)


QMタスクからの情報共有

メータティア1で行ったアンケート結果を共有.RedmineのQMタスクにて共有済み。

OSSの利用については各社ルールを持っているが、どのようなテストを実施しているかはばらばら。

採用している品質基準にISO26262がのっているが、主機能・安全機能にかかわらずISO26262を使っているということ？(山口)

そういう意味ではなく、品質基準の一つとして決まっていて、選択的に使っている(田口さん)

IVI開発会社はCMMiを使っているところが多い(西口さん)

テストのレベルがばらばらなのは、OSSのもってくる粒度によって決まるのではないか。良い例ではないが、例えばgstreamerを持ってくると、ホワイトボックステストはとれもできない規模なのでブラックボックステストを選択している。一方で、zlibであればホワイトボックステストが可能な規模なのでやっているなど。(山口)

ヒアリングではそこまでは聞いていないので、わからない。今後さらにヒアリングしていこうと考えている。(田口さん)

可能であれば、OSSをどのような粒度でもってきているのかを知りたい。(山口)


テストタスクからの情報共有

質疑応答のみ実施

先週のIC-EGの発表で、コーディングルールを決める必要があると言われていたが、実際にはどのようなコーディングルールを採用している？(山口)

昔は独自もあったが、今は*****になっている。(丸山さん)

Automotiveのよくあるコーディングルールは、OSSコミュニティのコーディングルールとは矛盾しているものもある。例えば、Linux KernelのコーディングルールとMISRAは、ifの{}のつけ方について相反するルールになっている。このへんも大きな課題。(山口)

同じ話を先週のIC-EGで話したときは、CERT Cも挙がった(山口)

宿題

田口さん、駒形さん

メータティア1のアンケートで、現在のOSSの採用粒度とテストやルールの関係性を確認する。

丸山さん

コーディングルールに関して、Linux KernelとGNUに対してギャップ分析を行う。

西口さん

今回時間の関係で話せなかったSWE.3について、ASPICEのドキュメントファーストとOSSのコードファーストが相反しているので、どういう理論建てをすればこの矛盾を解消できるのかを考える。

山口

今日のドキュメントの指摘事項のアップデート

SWE.3以降の検討

西口さんの宿題と同じ課題の検討


  • No labels