Build For Boards Sponsor Levels and Board Lifecycle
- 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:
- bug fixing
- boot testing
- Determine how we lead to EOL.
- Define support levels and responsibilities.
Platform maintains a sponsoring and support list for targets:
i.MX53 Quick Start
PandaBoard ES 1.1 release (OMAP4460)
- Maintain the table.
- One month before connect sponsors can notify about drops/pickups/changes of boards.
- During connect all requests are reviewed; here, sponsors can step up to continue supporting boards that lost sponsor; boards heading for the graveyard and other changes will be announced.
- Changes to board support become effective after the first release following the connect.
- If no new sponsor is found then a board is removed from list and re-adding can only happen using the same process again.
- Additions/removal/changes to LEB Support Level entries in this table need explicit linaro management ack as LEB Support Level comes with considerable commitments from Linaro Teams that don't act as Sponsor.
- actively engage in bug triage and resolution
- follow policy and meet deadlines set by release team
- take ownership of bugs found on your board; ensure release critical bugs are fixed or mitigated
- contribute release material content
- actively participate in the open community channels (IRC, mailing lists)
- PoC for release
Support is jointly owned by the Platform Team and the Sponsor. The level of engagement depends on the sponsoring level. What does support mean for LEB and Dev boards. We need to define it for all parties in Linaro, including the LTs?
- 3 boards for the lab (delivered and made ready for deploy by sponsor)
lab testing constrained to "Basic" (Boot & Basics) LAVA test suites
- Release Team tracks, but does not engage in bugs on this platform
- Manual Release Image QA is solely done by the sponsor
- Release Critical bugs must be resolved or mitigated for release by sponsor
- passive bug approach for platform team
- full lab equipment (20+ boards) - provided by Sponsor
- Platform QA
- hands on lab setup, deploy and monitoring/support by Validation team
- advanced instrumentation and test loads in lava lab (real audio testing, jtag, board provisioning)
- support for continuous testing using the full test repository; including long running smoke tests, benchmarks and one off lab submissions
- full CI services by Platform
- arbitrary amount of branches/build variants
- development of CI solution for not yet supported components
- monitoring and bug escalation for certain categories of bugs
- development of customized dashboard pages for LT needs
End Of Life
- What steps do we take when a board comes to EOL?
- No more LEB or Developer builds
- No more bugs, all new bugs are assigned to "linaro-community"
- All filed bugs are moved to a "linaro-community" group
- No "boot" testing, done by "linaro-community"
- No more LT support expected/needed
- Android manifests for those boards are no longer updated, moved to "linaro-community"
- Builds will no longer be mentioned in release notes
- Builds will no longer be QA'd
- 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...
Platform/RFCs/BuildForBoardsSponsorLevelsAndBoardLifecycle (last modified 2013-08-20 14:56:49)