Board Support Levels and Lifecycle
Define what levels of support to apply to boards and how they path that support levels can take
Define how board support gets picked up (BOL) and phased out (End Of Life)
Blueprint information
- Status:
- Not started
- Approver:
- Alexander Sack
- Priority:
- Undefined
- Drafter:
- David Zinman
- Direction:
- Approved
- Assignee:
- David Zinman
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Notes:
[anmar 2011/10/26] major questions we should answer:
I think the most relevant questions we need to answer are:
Q1. What does support mean for LEB and Dev boards. We need to define it for all parties in Linaro, including the LTs?
Q2. What steps do we take when a board comes to EOL?
[pfefferz 2011/10/20] Some thoughts:
Dropping boards means:
1. No more official builds at android-build
2. No more bugs, all new bugs are assigned to "linaro-community"
3. All filed bugs are moved to a "linaro-community" group
4. No "boot" testing, done by "linaro-community"
5. No more LT support expected/needed
6. Android manifests for those boards are no longer updated, moved to
"linaro-community"
7. Builds will no longer be mentioned in release notes
8. Builds will no longer be QA'd
9. A 1 month notice will be posted then the build will be dropped.
These steps call out an unorganized "linaro-community," The linaro-community lead would find community board sponsors and would give those sponsors access to our build site, and give them a list of QA tests, etc...
Goals:
* Define what EOL means:
* Maintenance after EOL
* Support for the community
* The obligations to LT's, Platform Teams and Community after a board is determined to be EOL.
* Consensus on what it means to EOL a board.
* Define Linaro's involvement with an EOL board:
* builds
* bug fixing
* boot testing
* How do we lead to EOL
* Get a high level agreement about EOL at Connect.
