Policies

Exceptions to the Apertis license expectations are listed below. Each exception must provide the following information: project The project name component The repository components apertis:*:target date The date at which the exception was added to this document validator The name of the person who validated the exception rule The rules that are ignored by this exception reason A description of why the exception is granted and makes sense elfutils project elfutils component apertis:*:target date September 17, 2019 validator andrewsh rule No GPL v3 reason elfutils is software dual-licensed as LGPL-3+ or GPL-2+, which means that any combined work using it has to be shipped under terms compatible with either of those two licenses. [Read More]

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 2 weeks before the hard code freeze. [Read More]

PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS SITE WHAT’S IN THESE TERMS? These terms tell you the rules for using our website “apertis.org”. WHO WE ARE AND HOW TO CONTACT US “apertis.org” is a site operated by Collabora Limited (“We”). We are registered in England and Wales as a limited company with registered number 05513718 and our registered office and main trading address is Platinum Building, Cowley Road, Cambridge, England, CB4 0DS. [Read More]

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. The currently recommended versions for evaluation can be found on the download page. Apertis provides images from daily build artifacts through to historic releases (which have reached their end of life) for supported platforms. This allows users and developers to both look at the latest changes as well as look at the historic state, which can be useful when testing just merged fixes and tracking down the origin of a bug respectively. [Read More]

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]

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]

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]

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]

This document covers the steps that should be taken at the various stages of making a contribution to Apertis with the rationale more fully explained in the policy. It covers both those steps to be taken by the contributor as well as the maintainer(s) accepting the contribution on behalf of Apertis. It is presented in this manner to provide transparency of the steps that are taken and the considerations that are made when accepting a contribution into Apertis, be that a modification of an existing component, addition of a new component or concept design. [Read More]

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. A checklist is provided in conjunction with these policies to aid contributors. TL;DR Do you want to quickly submit some changes to an Apertis component? Have you tried to submit your changes upstream first? [Read More]