freedesktop - Oct 2017 - [fdo] Freedesktop sdk aka 'tiny base runtime' project

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 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 [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 
runtime.

## 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 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.

## Licence

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.

## 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.

Thanks,
Laurence


[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk
[2] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/tree/test-conversions
[3] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/1
[4] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/milestones

Hi Laurence,

On 27 October 2017 at 15:45, Laurence Urhegyi
<laurence.urhegyi at codethink.co.uk> wrote:
> 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.
Thiago's questions would be good to have an elaborated answer on. In
particular, whether BuildStream - which seems like it's only a few
months old - is a core part of the 'API' for the SDK, or whether
it's
just incidentally used as part of the build process. I hadn't heard of
it until now, and would be curious to see if it's really used at all
outside of GNOME and Codethink.
> ## Objectives
>
> * Create and maintain a minimal base runtime using BuildStream definitions.
Same question as above: is the goal of the SDK to use BuildStream
definitions, or is BuildStream just something which happens to be a
part of it?
> * 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
> runtime.
I'd ideally suggest establishing the goals of the SDK in terms of what
it's meant to provide to external users. That's something which is
actually compelling and useful: fd.o doesn't usually get involved in
projects whose sole goal is to _use_ a new build system.
> 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.
For the record, I would very much like fd.o to migrate to GitLab.
> * Hardware will required at some point for the infrastructure.
What kind of hardware? Is that something you'd expect from fd.o, or
would you reuse, e.g. flathub and GNOME Continuous? Do you need
hosting, or build machines, or test runners, or ... ?
> ## Licence
>
> X / MIT
>
> No CLA to sign: All contributors hold their own copyright.
Is this just for the SDK - which I understand at this point to be a
bunch of build recipes and a conversion script from JSON/Yocto to
YAML/BuildStream - or are you talking about BuildStream itself?
> ## 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.
fd.o already has a Code of Conduct here, which we expect all new
projects to abide by:
https://www.freedesktop.org/wiki/CodeOfConduct/

If you have any specific input or suggestions, these would be welcome.

Cheers,
Daniel

Hi Daniel,

On 30/10/17 10:49, Daniel Stone wrote:
<snip>
> Thiago's questions would be good to have an elaborated answer on.
Let me know if Emmet and Tristan's respective explanations leave 
anything uncovered.

<snip>
> I'd ideally suggest establishing the goals of the SDK in terms of what
> it's meant to provide to external users.
Good point. We should emphasize the benefits to users better than I 
have. Tristan's point is pertinent here: the benefit is the reduced 
overhead from maintaining only one set of metadata.

<snip>
> What kind of hardware? Is that something you'd expect from fd.o, or
> would you reuse, e.g. flathub and GNOME Continuous? Do you need
> hosting, or build machines, or test runners, or ... ?
Setting up a runner for each architecture will be required. I expect 
that we can re-use what's already in use, yes, rather than needing to 
acquire anything new. Therefore we're not expecting anything from fd.o 
to this end.

<snip>
> fd.o already has a Code of Conduct here, which we expect all new
> projects to abide by:
> https://www.freedesktop.org/wiki/CodeOfConduct/
Thanks. These notes are just capturing discussions had: we would of 
course stick to that Code of Conduct.
> 
> If you have any specific input or suggestions, these would be welcome.
Thanks,
Laurence