Freedesktop sdk aka 'tiny base runtime' project

Laurence Urhegyi laurence.urhegyi at
Fri Oct 27 14:45:38 UTC 2017

Hi all,

So i wanted to kick off this mailing list by trying to round up a few 
things which have been discussed recently, at GUADEC, in f2f 
conversations afterwards, or shot over emails between a few people. It's 
been discussed for a while that we want to create a tiny base runtime 
with bst. The upshot is this will homogenize the metadata used in the 
build process for Flatpak, GNOME Continuous and eventually many other 
projects too, we hope.

Once we have something solid that works, we want to get it used by as 
many people as possible, so we'll need to do some publicity stuff. I 
have CC'd  freedesktop at and 
xdg at on this mail to try to raise awareness of what 
we're planning to do and involve them in the discussion.

We've set up on, for now [1]. There you can see the 
conversion script from JSON to bst [2] and [3], which is part of our 
first milestone.

So below is the summary of things discussed recently. All feedback / 
additions / corrections are welcome.

## Project Precis

A strap-line we came up with...

'This project maintains a compatible set of git repos and build 
instructions to provide other projects with a neutral stable base for 
operating system development'.

## Objectives

* Create and maintain a minimal base runtime using BuildStream definitions.
* Establish neutrally located infrastructure to host the base runtime.
* Implement an effective strategy for security updates to the runtime.
* Ensure that the base runtime works with the relevant tooling in 
Flatpak and GNOME Continuous.
* Replace flatpak builder with BuildStream to generate flatpak SDKs.
* Replace Freedesktop Base Runtimes (based on YOCTO) with the base runtime.
* Lastly, replace the GNOME Continuous (based on YOCTO) with the base 

## Roadmap

1) Make Buildtream-based SDK a dropin-replacement of the current one
2) Replace BaseSDK completely with BuildStream's Freedesktop SDK
3) Migrate to Freedesktop Infra
4) Convert GNOME Continuous to use the base runtime

See milestones on gitlab for further details and tasks under each 
milestone [4].

Some points on the above:
* We're on for now as an interim solution before we migrate 
to freedesktop infra, or freedesktop migrates to gitlab.
* Hardware will required at some point for the infrastructure.
* All infrastructure we establish must be repeatable and trivial to set 
up on another server.
* Architectures to aim for: armv7 (hard float only), aarch64, x86, and 
x86_64, all little endian.
* We'll aim first for the intel arches and hope for community help on 
the ARM side of things.

## Licence


No CLA to sign: All contributors hold their own copyright.

### List of uploaders

We'll choose 4 or 5 people to begin with (we'd discussed said Javier, 
Alex, Rob, Adam, Tristan). This list should be kept small: always less 
than 10. List people who can merge in git. Eventually set-up a post-job 
to update gitlab config automatically.

## Policy to become an uploader

An invite is required from someone already on the list of uploaders and 
then approval from a second person already on the list.

## Policy for maintenance of the list of the uploaders

Any changes to the list of uploaders requires review and approval by a 
second person who must also be from from the uploader list and is not 
the original submitter.

## Allowing merges and review process

For non-trivial changes, review is always encouraged. People with merge 
permissions can lose access due to inactivity, if the list of uploaders 
choose so. Access can be re-granted if required as described above.

## Release

We've discussed a rolling release: the aim is to continuously update the
runtime while keeping the ABI backward compatible for as long as
reasonably possible.

For the base runtime we expect multiple years of ABI stability to be
feasible (parallel installation of multiple versions may occasionally
be necessary for a few libraries).  When an ABI break is required
(e.g., C++ ABI break), the plan is to keep the previous branch
maintained (at least for security updates) for two years.

This should result in a rather small maintenance effort (1-2 branches at 
a time).

## Code of Conduct

We've discussed a simple but effective code of conduct, along the lines 
of: use common sense: don't abuse others and don't misbehave. When 
anyone does, folk should tell the mergers, who will be generally annoyed 
at the miscreants, and may take actions.

OK, so I think this covers all the initial important points, if I've 
missed anything then please feel free to add that.



More information about the xdg mailing list