Freedesktop sdk aka 'tiny base runtime' project
laurence.urhegyi at codethink.co.uk
Fri Oct 27 14:45:38 UTC 2017
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 lists.freedesktop.org and
xdg at lists.freedesktop.org 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 gitlab.com, for now . There you can see the
conversion script from JSON to bst  and , which is part of our
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'.
* 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
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
Some points on the above:
* We're on gitlab.com 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.
X / MIT
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.
We've discussed a rolling release: the aim is to continuously update the
runtime while keeping the ABI backward compatible for as long as
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
## 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