[Openembedded-architecture] Using GitLab for OE/Yocto layers

[Paul Barker]

Hey folks,

We had some initial discussion at OEDEM about the patch submission process and how repositories are hosted (see https://docs.google.com/document/d/1Qm1mJ6xLozWW9NgBnokue7TmhwgFP8b2HR8TUlaQwNs/edit#heading=h.o4qtddy8bh9i).

Patch submission via mailing list still has some key features (such as ability to compose a patch response offline) and I don't expect that the core OE/Yocto repositories will be changing their workflow in the short term. However, lots of tools and non-core layers already use a pull request model for patch submission, typically via GitHub or GitLab.

I'd like to propose that we set up a common place for OE/Yocto repositories which want to use this pull request model and start to collaborate on some of the tooling. As discussed in OEDEM, GitLab has a few major advantages over GitHub, BitBucket, etc here as they've got a track record of working well with open source projects and we can run the software on our own infrastructure if desired. We can use something like https://gitlab.com/openembedded at first to trial things and then maybe move to https://gitlab.openembedded.org (or gitlab.yoctoproject.org) if things look good.

I see the following advantages to this approach:

* Increased bus factor for repository administration - several layers currently have only one admin or live in someone's personal GitHub account, we risk losing access to these if the person in question disappears.

* Integrated issue tracking - we can standardise on a few issue labels and use milestones in GitLab to correspond to Yocto release branches. As the repositories would be in the same group we would be able to make use of group-level issue lists and boards to show issues across several layers.

* Integrated merge request tracking - Similar to issues, we would be able to see a combined group-level list of open merge requests. This is a good view to use to help out other layer maintainers as you can easily see new merge requests across all repositories and pick a few to review.

* Separation of patches to different repositories/branches - Where one mailing list takes patches for many repositories it's often confusing which repository or branch is the target for a given patch.

* Easier contribution from behind corporate firewalls or buggy email servers - contribution is via ssh/https.

* Subgroups - GitLab supports more than one layer of grouping so we can organise repositories even within the top level "openembedded" group.

* Ability to enable/disable merge requests per-repository - With GitHub you can't disable pull requests. If your repository takes patches by another method you have to manually watch out for pull requests and comment on each one to tell the contributor how to submit patches. With GitLab this isn't necessary as you can just turn off merge requests for that repository.

* Ability to standardise on automated testing - we can integrate patchtest and yocto-check-layer with GitLab CI and run these scripts on each merge request. This requires a bit of work in both test scripts to allow configuration as not all tests will be appropriate for all layers. However it's much easier than integrating these scripts with several incompatible repository hosts and CI systems.

* Ability to standardise on security - If we want to we can enforce two-factor authentication (2FA) for logins, make use of the merge request approvals feature in GitLab, etc. We don't need to do that initially but it may be useful in the future.

At the risk of bikeshedding I'd like to get some feedback on these ideas at this stage. Have I missed any advantages/disadvantages? Is anyone interested in helping to guinea pig this with a couple of layers/repositories to see how it works in practice?

-- 
Paul Barker