Branching and Release management

I’ve noticed a few different things happening around branching, so wanted a wider discussion

  1. We seem to be using ostc/master instead of devel for our development branch names in a few places. I recall that we’d decided that all development should happen in devel[1]. Should we fix these?
  2. Should we run with a unpinned manifest for most of our layers until feature freeze? IMO, this is acceptable during development, but there might be concerns about too much instability, so it is worth a discussion. Another way to think about this is that our default.xml manifest would always be unpinned (crack-of-the-day) but after feature freeze, we could have a release-v1.xml manifest that would track all the stable/release branches.
  3. Do we agree on the model of rebasing the devel branch until feature freeze so that:
    • All our local patches float to the top
    • Any patches that already got merged usptream throw conflicts and can get removed from the local set


For #2 it would be ideal to have some tests running on the merged code. That would avoid big breakage.

For #3 it seems OK for the development time

As discussed on mattermost, it would be a good idea to keep our branches prefixed with our own namespace. ostc was suggested, but perhaps something a bit neutral - asos, or something else.

So all local development branches could be asos/devel, for example.

Currently, all 1st party-maintained code in the All Scenarios OS project is automatically uploaded to Fossology at every commit on the main branch, in order to enable the audit team to constantly review it (see here).

However, also commits on development branches may need to be reviewed on Fossology in a separate “staging” area, f.e. when in a branch substantial portions of source code (or binary blobs) are going to be added or removed.

Since we cannot review every single development branch on Fossology, we should establish a policy for development branch names that should be scanned with fossology – a policy that can be automatically implemented through GL pipeline definitions, eg. via regex (in .gitlab-ci.yaml you can use if clauses like if: '$CI_COMMIT_BRANCH =~ /regex-expression/'). We could use a suffix or a prefix in branch name, or use slashed branch names (like feat/foo/fossy).

Any suggestion or feedback on that is welcome!

How about using the DFSG acronym which seems to have the same goal - to adjust the original source to be acceptable (to Debian, in the original sense) but perhaps our goals are the same?

It would make sense, for third party code forked within AllScenariOS. But we should replace the “D” with something else :slight_smile: and in any case, we should discuss whether we are willing to apply DFSG to AllScenariOS (which would be a good idea, I guess, but it needs to be discussed in the WG)

Another important point is reproducibility. In principle, any audit must be reproducibile, so the build against which an audit has been done must be always reproducible, too.

This principle holds in any case for audits on project releases (alpha, beta, rcX, GA); it could be relaxed only for interim/preliminary audits, i.e. audits meant to provide just a preliminary assessment on a new sw component or set of sw components that developers are thinking to include in a release.

The problem is that AllscenariOS project is based on a manifest that points to commits on git repos, but those commits may disappear over time due to git history rebases.

I understand that one can try to limit, but cannot completely avoid git rebases over time. So some technical solution should be found so that commits included in manifests of audited project releases are never deleted from the relevant git repos, or at least they are cached/mirrored in some way