...
Describe about detailed reusing existing OSS criteria when AGL use existing OSS.
This section mainly describes what to do when incorporating OSS into the main source code.
Process side:Tasks
D.1 Check for Change logs
D.2 Create release note
Technical side:
Should check the following criteria.
D.1 Change logs
...
Compare "change logs" and "source code changes" and confirm that there are no unintended changes.
Create the document of confirmation results. (#リリースノートに記載すればOKか？)
D.2 Check for Fixed bugs with the change logs
...
XXX
note : 一般的にOSSの既存bugはどのように管理されているのか？DeviationListなどが存在するのか？
D.3 Check for New bugs by static analysis tools (or test report)
...
Check for new bugs that not intended.
D.4 Check for Coding rules by static analysis tools
...
Use static analysis tools to check compliance with AGL coding rules.
D.5 Check for Software interface specification
...
Check the source code and library software interface specifications provided by OSS.
D.6 Check for Memory usage about ROM / RAM (
...
#結合テストプロセスで確認するべき？)
...
Evaluate compliance with AGL Instlment Cluster Specification.
D.7 Check for Performance spec (
...
#結合テストプロセスで確認するべき？)
Evaluate compliance with AGL Instlment Cluster Specification.
D.8 Create the release note
XXX
Deliverable
D.X Release note document
D.X
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
（memo）
本文(AGL Instrument Cluster Development Process Draft)のセクション2.2のクライテリアを具体的に明示するArchitectural criteria of the reusing existing OSSと同様に、
セクション3.2のクライテリアを具体化する文章です。
セクション2.2は、使用するOSSの選択とメジャーバージョンの決定にフォーカスしています。
一度実施してしまえば、基本的には差分のみを見るようなセクションです。
セクション3.2は、このリリースで使用するバージョン(マイナバージョン)の決定、既知の脆弱性の洗い出しなど、実際に使用するソースコードに対する
アセスメントにフォーカスするのが良いのではないかと考えています。
着目点が違うなど、異なる見解であれば、整合性はあとでとればよいので、田口さんの視点で書いていただいて構いません。
アーキテクチャ設計は毎回やることではない。→section 2.2の範囲
section 3.2では、"OSSのVupごとにやること"を明確にしていくようなイメージ。