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

[Paul Barker]

Following up on the email below, I've created a "community" subgroup to the OpenEmbedded group on GitLab: https://gitlab.com/openembedded/community. This should help to avoid any confusion with the repositories at the top level of https://gitlab.com/openembedded which mirror those at git.openembedded.org.

I'm going to use this for one or two layers I'm currently developing. If anyone else would like to setup a new layer here or transfer/mirror a repository from elsewhere then let me know and I'll get you set up.

On Wed, 6 Nov 2019, at 16:01, Paul Barker wrote:
> 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
> -- 
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd