CIP testing management

In this section you can follow how the project is progressing and the plans for the coming weeks. As described in the CIP Testing project description page, 4 actions describe what this effort is about. These actions have been decomposed into several milestones, described below. Please take dates as estimations and early plans, not commitments. Check the diagram for further detail:

• B@D Improvements (orange): tasks related with updating B@D and adding new functionality requested by CIP Members or required to accomplish the overall goals (again, described in the CIP Testing project description page.
• Action 2 preps and signing (gold/pear): preliminary tasks to configure B@D capabilities needed to reach the goals of this second action. One of the key ones, originally not fully supported by LAVA and KernelCI, is the handling of signatures/hashes so we ensure that the main components of the environments (tests, logs, reports, kernels/systems, firmware, etc) are signed so CIP Members can trust the obtained results.
• Health-checks (blue): the current health-check needs to be improved in order to guarantee that the correct tests, board, B@D version, system version, etc. are being used during the testing process before sharing the testing results, as a way to guarantee that they are meaningful and, up to certain point, reproducible.
• Reporting (pink): the current reports that LAVA and KernelCI produce are designed for the kernel (developer) community. They need to be adapted to the CIP use case, which is more focused on maintenance.
• Increase test Coverage (green): once the system is configured, the focus will turn into increasing the test coverage of both, the CIP kernel and the core system.
• ELCE 2017 (yellow): ELCE is a major milestone for CIP, so for the CIP Testing project. Some key tasks will be executed during and before the event to promote the usage of B@D and to discuss future steps.

The current diagram is a modified kanban board that shows the current state of the Testing project at a high level. It will be updated regularly. For a more fine grain analysis, please check CIP testing management instance at gitlab.com.

The current goal is to present at ELCE the testing environment working, leaving refinements and non-critical tasks for the weeks after the event. Please take dates as estimations and early plans, not commitments.

You can follow closely the CIP testing project status through the kanban board but for those who are working on the project, the kanban board might not be enough. At CIP Testing project we complement it with the project journal, that later on were adopted for other activities.

The project journal is a diary of what those involved in the project do on daily basis. The current team at CIP is geographically distributed and works in an asynchronous mode so the journal becomes a good tool to tell your team mates what are you up to while keeping overview of your own effort daily and weekly. This is the main tool used to create the reports sent regularly to the mailing list about the activity done by the team.

Check the CIP project journal ground rules to understand how it works.

The current team behind the CIP Testing project are:

• Robert Marshall - Codethink Ltd Lead engineer
• Agustín Benito Bethencourt - Codethink Ltd. Sometimes management but most of the time housekeeper and or butler. Very soon also gardeining (watering the seeds).
• Collaborators:
  • Tom Pollard - Codethink Ltd.
  • Ben Hutchings - Codethink Ltd.

Obviously there are other CIP developers involved in this effort like Daniel Sangorrin (Toshiba), Chris Paterson (Renesas) that help this team when required.

Other past members and collaborators:

• Don Brown - Codethink Ltd.
• Christos Karamitsos - Codethink Ltd.
• Lachlan Mackenzie - Codethink Ltd.

You can contact them all through the cip-dev mailing list.

Description of the processes and practices involved in the delivery of Board at Desk tools

• Check the CIP testing project bugs board

The release process for B@D v1.0 has been structured around 6 main tickets.

• #141 Release B@D v1.0. This is the task that track the whole process so it is the one to follow by those interested in a higher level view of the process. It includes the most relevant tasks.
• Each phase of the process is detailed in a single task:
  • #142 B@D v1.0 release: Gold Master declaration.
  • #143 B@D v1.0 release: deployment.
  • #144 B@D v1.0 release: documentation. If the project grows, the recommendation is to split this tasks in several. The task is structured so that splt is easy to do.
  • #146 B@D v1.0 release: marketing material preparation. This task heavily depedsn on the type of project you work on and in the possibility or not to have a marketing team. In our current process, our marketing effort is very limited and we heavily rely on the Linux Foundation effort.
  • #147 B@D v1.0 release: publishing

Please check the CIP testing releases wiki page to find out about previous releases of projects/products delivered by CIP testing project. If you are interested in the current version of B@D please start from the Board At Desk landing page.

All the content related with marketing releases and B@D in general has been moved to the B@D marketing wiki page