Release Schedule

Apertis has a three month release cycle. Development happens through most of the cycle with emphasis on bug fixing towards the end. The quarterly release cycle was chosen as it fits well with the fast paced development of Apertis. Release timeline The Apertis release cycle starts at the end of the previous release cycle. At this point, new features are proposed, discussed and implemented. The soft feature freeze takes place about 4 weeks before the bug fixing stops. [Read More]

Roadmap

This is a rough list of areas which are planned to be worked on in releases in the near future. This is not a full list and is intended to be used only as a rough guide and is subject to change. 2020 Q3 Concepts Use of Eclipse hawkBit for Apertis updates Addition of NTFS support for offline updates HMI Import of agl-compositor as a reference HMI Infrastructure Move project health checks from Jenkins to GitLab CI pipelines Evaluate need for further testing and monitoring of Apertis infrastructure Move tiny-image-recipe build pipeline from Jenkins to GitLab CI System Update Integration of Eclipse hawkBit as update option Q2 Concepts Integration of OP-TEE Automated OSS compliance Addition of exFAT support for offline updates Documentation Integrated search on www. [Read More]

Hardware Enablement

This page documents what is required from hardware platform (and specifically the software interfaces used) to integrate well into Apertis. For Apertis to easily support a variety of hardware platforms, it is important that a consistent set of user space components can be used across the range of supported devices. To achieve this (in-line with its Upstream First strategy), Apertis relies on upstream interfaces and frameworks to access the hardware. Interfaces that aren't supported upstream (or cannot go upstream for whatever reason) require extra effort to support, test and maintain. [Read More]

HWpack Requirements

This documentation covers the requirements and considerations that should be taken into account when implementing “hardware packs” for the Apertis project. Concepts This section briefly covers the concepts and expectations of the Apertis platform. Image Building Stages Apertis images are built from binary packages, packaged in the .deb format. Building these packages is expected to be carried out from source by the Apertis infrastructure, ensuring all packages dependencies are properly described and reducing the risk of unexpected dependencies. [Read More]

Community

Apertis is a free software project which is designed and developed in the open. The Apertis community is made up of both contributors who work to improve Apertis and users. Join the community The best ways to get in touch with the community are through: Mailing lists The devel mailing list is the place to discuss Apertis development and project If you are interested in adding a new mailing list, please contact listmaster at apertis. [Read More]

Upstreaming

Upstreaming changes made to a piece of Open Source software provides distinct advantages for the author of the changes and the ecosystem of users of software. The author can expect to see: Reduced overhead in on-going maintenance of their code base: With the changes available in the upstream version, the author will no longer need to port changes when upgrading to a newer version of the software. Reduced risk of incompatible changes and/or features being added to the upstream code base: When making local modifications to a code base, there is a risk that at some future point any local changes will fail to apply without significant changes or a comparable feature will be implemented with different semantics requiring either conversion to this feature to be carried out or continuing to carry the local change with much reduced advantages. [Read More]

Coding Conventions

This document specifically relates to software which is or has been created for the Apertis project. It is important that any code added to an existing project utilises the coding conventions as used by that project, maintaining consistency across that projects codebase. Coding conventions is a nebulous topic, covering code formatting and whitespace, function and variable naming, namespacing, use of common GLib coding patterns, and other things. Since C is quite flexible, this document mostly consists of a series of patterns (which it’s recommended code follows) and anti-patterns (which it’s recommended code does not follow). [Read More]

Contribution Process

This guide covers the expectations and processes for Apertis developers wishing to make contributions to the Apertis project and the wider open source ecosystem. These policies should be followed by all developers, including core and third party contributors. Suitability of contributions Like most open source projects, Apertis requires contributions are submitted via a process (which in the case of Apertis is defined below) to ensure that Apertis continues to meet it's design goals and remain suitable for it's community of users. [Read More]

Images

Apertis has a release lifecycle which is roughly three months long. Each release consists of a round of development, testing and bug fixing, followed by a stable release. Apertis also has a daily set of images which can be used for the latest testing. You can find: stable release images daily build images Apertis is actively developed, so you should always develop against either the latest release or the daily build images. [Read More]

Package maintenance

Apertis hosts its own package subset on the Apertis GitLab instance. On successful completion of the CI pipeline these are uploaded to Collabora's Open Build Service (OBS) instance where the packages are formally built and hosted for Apertis. Packages Guidelines The package set is distributed in several groups: target, development, sdk, hmi, helper-libs. Those groups are merged in a single repository, and split in what distribution names repository components (target, development, sdk, hmi, helper-libs). [Read More]