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@...
https://lists.yoctoproject.org/listinfo/yocto