[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Using gitlab for upstream qemu repo?
From: |
Eric Blake |
Subject: |
Re: [RFC] Using gitlab for upstream qemu repo? |
Date: |
Thu, 22 Oct 2020 12:24:28 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 |
On 10/22/20 11:47 AM, Paolo Bonzini wrote:
> Hi all,
>
> now that Gitlab is the primary CI infrastructure for QEMU, and that all
> QEMU git repositories (including mirrors) are available on Gitlab, I
> would like to propose that committers use Gitlab when merging commits to
> QEMU repositories.
>
> Nothing would change for developers, who would still have access to all
> three sets of repositories (git.qemu.org, gitlab.com and github.com).
> Committers however would need to have an account on the
> https://gitlab.com/qemu-project organization with access to the
> repositories they care about. They would also lose write access to
> /srv/git on qemu.org.
For clarification, I'm assuming the set of committers is rather small,
and not the same as the set of subsystem maintainers who send pull
requests for a committer to then merge in. Does this proposal mean that
pull requests would have to switch to gitlab merge requests, or would
there be a transition period where submaintainers still send pull
requests via whichever means desired (mail or gitlab merge request), but
the eventual committer repackages that as a gitlab merge request before
it is upstream?
>
> Of course this is just starting a discussion, so I'm not even proposing
> a date for the switch.
I'm hoping that as part of the consideration that we make sure that
command line tooling can still drive everything; there is a difference
between requiring a web page to initiate a merge request, vs. proper
command line tooling one to leave the web page as an optional part of
the workflow for only those who want it.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org