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 > [email protected] > https://lists.yoctoproject.org/listinfo/yocto > -- Paul Barker Managing Director & Principal Engineer Beta Five Ltd _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
