---
title: "Maintainers' Meeting, August 22, 2022"
tags: unikraft, maintainers
datetime: 2022-08-22T11:00:00+02:00
location: Online, Discord (https://bit.ly/UnikraftDiscord), the `#maintainers-voice` voice channel
teams:
- maintainers
participants:
- RazvanD
- MarcR
- CezarC
- MichalisP
- StefanJ
- SimonK
- VladB
- AlexJ
---

## :dart: Agenda

- plat re-architecting (Michalis)
- bootloader support + packaging (Alex, Simon, Cristi)
- memory randomization (+loading) (Marc, Simon)
- branch / tag management: release tags, stable branches, development branches
- code analysis integration

## :closed_book: Discussions

### Branch, Tag, Release and Version Management

AJ: Currently, `staging` is used for development.
Everything is merged into `stable` every release.
Development happens on `staging`.
This is the default branch on GitHub, when cloning the repository.

PRs would be automatically added into `stable` if they pass everything on the CI/CD.
This will enable faster releases.

The positive outcomes of a (periodic) release is it gets buzz and publicity.

AJ: The CI/CD will verify tests and, if PR is successful, the PR will be integrated in `stable`.

SK: We now have `staging` as the default branch.
Which is why we are doing a `staging-v2`.
I think `stable` should be the default branch.
Then changes will be first integrated in `staging` and then in `stable` if tests are passed.

AJ: The problem of indicating the version compatibility is not integrated in Unikraft.

SK: We have this combination of the library version bound to a given Unikraft version.

MP: You can have two tags: a library-specific tag, and one belonging to the relase library.

AJ: Say you have lwip with 3 different versions.
What if a vulnerability?
Do we use the most recent version or do we go back and update them all?

AJ: We should be automating as much as we can out of the release schedule.
The release is quite a difficult process.

RD: The release schedule is useful to get the community motivated to update and review PRs.
This shouldn't go away.

SK: Agree, we should keep the release schedule.

AJ: A version is a string I can concretely refer to.
If I'm using Unikraft, I can ask someone to use the specific version.

RD: What is not-automated and can be automated?

AJ: There was an id in the README of the release, that I missed.
That part should be automated.
Adding the integration tests in the CI/CD system.

AJ: There are a number of things that should be part of the review process and that are not in there: unit tests, integration testing, code analysis, maybe performance checks via Wayfinder.

SK: To use `stable` as the default branch, we require the integration tests in the CI/CD system.

RD: What is the difference between `staging` and `stable`?

SK: One example is Musl.
Musl breaks stuff.
PRs go in but move into `staging`.

RD: But for something that is not breaking?
The reviewer and assignee could work on a PR and make it ready for `stable` from the start.

SK: Yes, they would move to `staging` and then quicky into `stable`.
This is fine.
`staging`, for non-breaking changes, is more of a transitory branch.

SK: This should be the same model on all repositories (core, libraries, applications), otherwise it doesn't make sense.

AJ: Changes to a library should go through all applications to verify if everything works.

### Towards Release 0.11

SK: This week will be used to add all Musl-related PRs.

RD: Simon, you need to create a PR with the Unikraft updates (scheduling, posix-process).
The PR will use the `staging-muslpreview` branch as the target.

Once 0.11 release happens, the `staging-muslpreview` branch will become `staging`.

Applications and libraries have to be working with Musl by the release.

RD: There are issues with the `posix-socket`, `posix-event` internal libraries that aren't mentioned in the `Config.uk` files of application library repositories (`lib-redis`, `lib-nginx`).
I'm working with Maria Sfîrăială to fix those.

## :wrench: TODOs and Decisions

AJ: Rearchitect CI/CD system to integrate the stable branch integration of new features.

`stable` will the default branch.
Approved PRs go into `staging`.
Then, after passing integration tests, they would move into `stable`.
A move into `stable` of a PR / feature in any repository, will cause a new tag to be created and added to all repositories.
This means we will have tens of tags between releases.

A release is going to be tied to the release schedule.
A release will be decided by the community based on features available on the `stable` branch.
A relase and fill feature a major release tag that will be added to all repositories.

The move to the new model using `stable` as the default branch is reliant on the CI/CD-based integration tests happenning.
A realistic deadline is release 0.12 (late November).

We will discuss later on including upstream library versions into the branch / tag / release model.

RD: Schedule CI/CD discussion for integration tests.

RD: Schedule community leaders discussion.

RD: Schedule 1 year OSS planning discussion.

SK: Create Unikraft PR with scheduling updates on the `staging-muslpreview` branch.

We will create `staging-muslpreview` branches on different repositories as they are required (likely `lib-newlib`, `lib-lwip`, library repositories).

RD/MS: Fix application library repositories (`Config.uk`) to feature dependencies on new internal libraries (`posix-socket`, `posix-event`).