...
Describe about detailed reusing existing OSS criteria when AGL use existing OSS.
These specifications should include the following criteria.
D.1 Confirm the change logs
D.2 Confirm fixed bugs with the change logs from major version
D.3
This section mainly describes what to do when incorporating OSS into the main source code.
Tasks
T.1 Check for Change logs
Check the "change logs" and compare with "source code changes" , confirm that there are no unintended changes.
Create the document of verification results or write in the release note.
T.2 Check for Fixed bugs with the change logs
Use the "Bug Tracking System" to check the details of the bug based on the "Fixed bug ID" in the change logs.
Create the document of check results or write in the release note.
note) BTS(Bug Tracking System) reference
- Redhat : https://bugzilla.redhat.com/
- Debian : https://www.debian.org/Bugs/
T.3 Check for New bugs by static analysis tools
Use static analysis tools to check for new bugs
...
that there are no unintended.
Create the document of check results or write in the release note.
T.4 Check for Coding rules by static analysis tools
Use static analysis tools to check
...
compliance with AGL coding rules
...
D.5
D.6
（山口さんメモ）
本文(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ごとにやること"を明確にしていくようなイメージ。
・実行速度
・メモリ使用量（ROM/RAM）
・どんな機能を提供しているか
・I/F(結合仕様)の確認、明確になっているか。あとは評価
・使用実績
...
.
Create the document of check results or write in the release note.
T.5 Check for Software interface specification
Check the source code and library software interface specifications provided by OSS.
The important point is to check compatibility from previous version.
Create the document of check results or write in the release note.
T.6 Create the release note
Create a release note and include the following information.
- Date
- Distribution version
- OSS name
- OSS version
- OSS URL
- OSS license
- Summary
- Static Analysis Summary
note) If you have any other need points, please comment anything.
note) ソフトウェア要件との適合性も見るべき？レグレッションテストの観点では必要なので、TestSpec側とどちらかで考えは含めておくこと。
Deliverable
D.1 Report of the above tasks
D.1-1 Verification results about comparing "change logs" and "source code changes"(T.1)
D.1-2 Results about Checking for Fixed bugs(T.2)
D.1-3 Results about Checking for New bugs(T.3)
D.1-4 Results about Checking for Coding rules(T.4)
D.1-5 Results about Checking for Software interface specification(T.5)
D.2 Release note(T.6)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Purpose
- Determine the role of that software component in the AGL instrument cluster software platform.
Entry Criteria
- E3.2-1 The extraction of the relevant software components shall be completed.
Tasks
- T3.2-1 Create/update software component use case diagram and description
Create a use case document to show why the that OSS is needed. This document shall be including all of assigned platform functional requirement.
- T3.2-2 Assess to the reusing existing opensource software
OSS assess and certify based on the AGL Instrument Cluster Distribution Criteria.
- T3.2-3 Determine a major version of the OSS
The major version of the OSS shall be selected with a maintenance lifecycle that meets the roadmap creating in section 1. When it OSS is not provided Long Term Support/Stable by upstream, should select downstream that is maintained by distribution.
AGL should select and refer to downstream of one distribution (RedHat/CentOS or Debian or Ubuntu or OpenSUSE or other), not select Yocto code base.
Verification
- V3.2-1 Review the use case diagram and description
TBD.
- V3.2-2 Review the assessment result
TBD.
- V3.2-3 Review the test .
TBD
Exit Criteria
- X3.2-1 TBD
Deliverable
...
（memo in Japanese）
本文(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ごとにやること"を明確にしていくようなイメージ。