Hey folks,

We had some initial discussion at OEDEM about the patch submission process and 
how repositories are hosted (see 

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 

* 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
yocto mailing list

Reply via email to