[RFC] Using gitlab for upstream qemu repo?

[RFC] Using gitlab for upstream qemu repo?

[Paolo Bonzini]

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.

There are four reasons for this:

- this would be a step towards ensuring that all commits go through the
CI process, and it would also provide a way to run the deployment of the
web site via .gitlab-ci.yml.

- right now Gitlab pulls from upstream repos and qemu.org pulls from
gitlab, but this is not true for the qemu, qemu-web and openbios
repositories where Gitlab pulls from qemu.org and qemu.org is the main
repository.  With this switch, all the main repositories would be on
Gitlab and then mirrored to both qemu.org and GitHub.  Having a
homogeneous configuration makes it easier to document what's going on.

- it would limit the number of people with access to qemu.org, since
committers would no longer need an account on the machine.

- by treating gitlab as authoritative, we could include it in the
.gitmodules file and remove load on the qemu.org server

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.

Of course this is just starting a discussion, so I'm not even proposing
a date for the switch.

Paolo

Re: [RFC] Using gitlab for upstream qemu repo?

[Eric Blake]

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

Re: [RFC] Using gitlab for upstream qemu repo?

[Gerd Hoffmann]

  Hi,

> 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.

Yes.

> Does this proposal mean that
> pull requests would have to switch to gitlab merge requests,

I mirror my stuff to gitlab/github anyway, for CI coverage.  Increases
the chance that errors are catched by CI not Peter.  With that already
in place the step to do a gitlab pull req is pretty small.

Nevertheless that is a separate discussion.
Can gitlab properly handle signed tags btw?

> > 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.

Gitlab has a JSON API, scripts/ci/gitlab-pipeline-status uses that for
example.  I'm pretty sure there are gitlab cli tools using that API ...

take care,
  Gerd

Re: [RFC] Using gitlab for upstream qemu repo?

[Daniel P. Berrangé]

On Thu, Oct 22, 2020 at 06:47:55PM +0200, 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.
> 
> There are four reasons for this:
> 
> - this would be a step towards ensuring that all commits go through the
> CI process, and it would also provide a way to run the deployment of the
> web site via .gitlab-ci.yml.
> 
> - right now Gitlab pulls from upstream repos and qemu.org pulls from
> gitlab, but this is not true for the qemu, qemu-web and openbios
> repositories where Gitlab pulls from qemu.org and qemu.org is the main
> repository.  With this switch, all the main repositories would be on
> Gitlab and then mirrored to both qemu.org and GitHub.  Having a
> homogeneous configuration makes it easier to document what's going on.

I think it makes sense to make GitLab be the canonical location for
all the GIT repos that QEMU project hosts, and everything else be a
read-only mirror.

With the current mixed setup both qemu.org and gitlab.com are failure
points which impact us. This is bad because while gitlab.com has
scalable redundant hardware with dedicated sysadmins, qemu.org is a
single VM, with part time sysadmins, and no failover facility if the
VM fails.

By making gitlab.com primary, any problems with qemu.org no longer
have a blocking impact on us.

> - it would limit the number of people with access to qemu.org, since
> committers would no longer need an account on the machine.
> 
> - by treating gitlab as authoritative, we could include it in the
> .gitmodules file and remove load on the qemu.org server

Yes makes sense,

> 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.
> 
> Of course this is just starting a discussion, so I'm not even proposing
> a date for the switch.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC] Using gitlab for upstream qemu repo?

[Daniel P. Berrangé]

On Thu, Oct 22, 2020 at 12:24:28PM -0500, Eric Blake wrote:
> 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.

Since Paolo's only suggesting move of the git server here, it should not
impact anything that is done today. Any CLI tools that talk plain git
to git.qemu.org will work unchanged against git.qemu.org or gitlab.com.


To answer your question though, GitLab has an extensive REST API that
lets you drive almost everything that is exposed in their Web UI. There
is my own Bichon tool (https://gitlab.com/bichon-project/bichon) that
uses the API to provide an interactive terminal based review UI, while
the Lab tool (https://github.com/zaquestion/lab) provides a text based
non-interactive CLI for use from shell/scripts again using the REST
API.


Not commonly known is that GitLab also has support for Git push options,
which let you create merge requests using a plain "git push":

  https://docs.gitlab.com/ee/user/project/push_options.html

eg if you have a remote called "gitlab", you can open a MR from the CLI
using

 $ git push -o merge_request.create \
            -o merge_request.title="Do awesome thing" \
            gitlab my-branch

This is something that I could see being easily wired up into a
"git-publish" like tool for example.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC] Using gitlab for upstream qemu repo?

[Paolo Bonzini]

On 22/10/20 19:24, Eric Blake wrote:
> 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?

No, all it means is that Peter would have to do "git push gitlab"
instead of "git push origin" :) and likewise for qemu-web and openbios.

I'm open to switching (later) to merge requests for qemu-web, but that's
a different story.

Paolo

Re: [RFC] Using gitlab for upstream qemu repo?

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Fri, Oct 23, 2020 at 09:51:31AM +0100, Daniel P. Berrangé wrote:
> Not commonly known is that GitLab also has support for Git push options,
> which let you create merge requests using a plain "git push":
> 
>   https://docs.gitlab.com/ee/user/project/push_options.html
> 
> eg if you have a remote called "gitlab", you can open a MR from the CLI
> using
> 
>  $ git push -o merge_request.create \
>             -o merge_request.title="Do awesome thing" \
>             gitlab my-branch
> 
> This is something that I could see being easily wired up into a
> "git-publish" like tool for example.

Nice, thanks for mentioning this GitLab feature.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC] Using gitlab for upstream qemu repo?

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On Thu, Oct 22, 2020 at 06:47:55PM +0200, 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.
> 
> There are four reasons for this:
> 
> - this would be a step towards ensuring that all commits go through the
> CI process, and it would also provide a way to run the deployment of the
> web site via .gitlab-ci.yml.
> 
> - right now Gitlab pulls from upstream repos and qemu.org pulls from
> gitlab, but this is not true for the qemu, qemu-web and openbios
> repositories where Gitlab pulls from qemu.org and qemu.org is the main
> repository.  With this switch, all the main repositories would be on
> Gitlab and then mirrored to both qemu.org and GitHub.  Having a
> homogeneous configuration makes it easier to document what's going on.
> 
> - it would limit the number of people with access to qemu.org, since
> committers would no longer need an account on the machine.
> 
> - by treating gitlab as authoritative, we could include it in the
> .gitmodules file and remove load on the qemu.org server
> 
> 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.
> 
> Of course this is just starting a discussion, so I'm not even proposing
> a date for the switch.

Thanks, this sounds good. It will simplify qemu.org administration.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC] Using gitlab for upstream qemu repo?

[Peter Maydell]

On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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.

Yes, this makes sense. Who in practice does it actually affect?
For the main qemu.git repo, my guess is just me, Michael Roth
for the stable branches, plus Richard H and Stefan H who both
volunteered to do a turn on the merge-handling rota once we
eventually get it set up to not depend on my ad-hoc CI setup.

I have a gitlab account so I'm set for this. Michael, do you
have an account there and are you OK with switching to doing
git pushes to the repo on gitlab rather than direct to qemu.org ?

thanks
-- PMM

Re: [RFC] Using gitlab for upstream qemu repo?

[Michael Roth]

On Mon, Oct 26, 2020 at 11:04:06AM +0000, Peter Maydell wrote:
> On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 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.
> 
> Yes, this makes sense. Who in practice does it actually affect?
> For the main qemu.git repo, my guess is just me, Michael Roth
> for the stable branches, plus Richard H and Stefan H who both
> volunteered to do a turn on the merge-handling rota once we
> eventually get it set up to not depend on my ad-hoc CI setup.
> 
> I have a gitlab account so I'm set for this. Michael, do you
> have an account there and are you OK with switching to doing
> git pushes to the repo on gitlab rather than direct to qemu.org ?

That's fine by me. My gitlab account is @mdroth, and I've requested
access to qemu.git and qemu-web.git subgroups.

My only concern would be what the lag time might be between updates to
qemu-web.git and the actual website update if the mirroring doesn't
right away. Probably not a huge deal but might be good to know what the
upper bound is if we want to verify the update process went okay.

> 
> thanks
> -- PMM

Re: [RFC] Using gitlab for upstream qemu repo?

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3023 bytes --]

On Mon, Oct 26, 2020 at 11:04:06AM +0000, Peter Maydell wrote:
> On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 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.
> 
> Yes, this makes sense. Who in practice does it actually affect?
> For the main qemu.git repo, my guess is just me, Michael Roth
> for the stable branches, plus Richard H and Stefan H who both
> volunteered to do a turn on the merge-handling rota once we
> eventually get it set up to not depend on my ad-hoc CI setup.
> 
> I have a gitlab account so I'm set for this. Michael, do you
> have an account there and are you OK with switching to doing
> git pushes to the repo on gitlab rather than direct to qemu.org ?

Here are the users with commit access to qemu.org repos:

berkeley-softfloat-3 - pmaydell,mdroth,stefanha
berkeley-testfloat-3 - pmaydell,mdroth,stefanha
capstone - pmaydell,mdroth,stefanha
dtc - pmaydell,mdroth,stefanha
edk2 - pmaydell,mdroth,stefanha
ipxe - kraxel,lprosek
keycodemapdb - pmaydell,mdroth,stefanha
libslirp - pmaydell,mdroth,stefanha
meson - pmaydell,mdroth,stefanha
openbios - pmaydell,mdroth,stefanha
openhackware - pmaydell,mdroth,stefanha
opensbi - <none>
qboot - pmaydell,mdroth,stefanha
qemu - pmaydell,mdroth,stefanha
qemu-jeos - pmaydell,mdroth,stefanha
QemuMacDrivers - pmaydell,mdroth,stefanha
qemu-palcode - pmaydell,mdroth,stefanha
qemu-stable-0.10 - jforbes,afaerber,mdroth
qemu-stable-0.14 - jforbes,afaerber,mdroth
qemu-stable-0.15 - jforbes,afaerber,mdroth
qemu-stable-1.0 - jforbes,afaerber,mdroth
qemu-stable-1.1 - jforbes,afaerber,mdroth
qemu-stable-1.2 - jforbes,afaerber,mdroth
qemu-stable-1.3 - jforbes,afaerber,mdroth
qemu-stable-1.4 - jforbes,afaerber,mdroth
qemu-web - paolo,jcody,pmaydell,mdroth,thuth
s390-tools - pmaydell,mdroth,stefanha
seabios - pmaydell,mdroth,stefanha
seabios-hppa - pmaydell,mdroth,stefanha
sgabios - paolo
skiboot - pmaydell,mdroth,stefanha
SLOF - pmaydell,mdroth,stefanha
u-boot - pmaydell,mdroth,stefanha
u-boot-sam460ex - pmaydell,mdroth,stefanha
vbootrom - pmaydell,mdroth,stefanha
vgabios - pmaydell,mdroth,stefanha

Quite a few of those repos are mirrors and actually don't need human
push access.

The people who need push access are:
 * bonzini - qemu-web
 * mdroth - qemu-stable
 * pmaydell - qemu
 * rth - qemu
 * stefanha - qemu
 * thuth - qemu-web

Does this sound good?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC] Using gitlab for upstream qemu repo?

[Daniel P. Berrangé]

On Tue, Oct 27, 2020 at 02:08:18PM +0000, Stefan Hajnoczi wrote:
> On Mon, Oct 26, 2020 at 11:04:06AM +0000, Peter Maydell wrote:
> > On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > > 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.
> > 
> > Yes, this makes sense. Who in practice does it actually affect?
> > For the main qemu.git repo, my guess is just me, Michael Roth
> > for the stable branches, plus Richard H and Stefan H who both
> > volunteered to do a turn on the merge-handling rota once we
> > eventually get it set up to not depend on my ad-hoc CI setup.
> > 
> > I have a gitlab account so I'm set for this. Michael, do you
> > have an account there and are you OK with switching to doing
> > git pushes to the repo on gitlab rather than direct to qemu.org ?
> 
> Here are the users with commit access to qemu.org repos:
> 
> berkeley-softfloat-3 - pmaydell,mdroth,stefanha
> berkeley-testfloat-3 - pmaydell,mdroth,stefanha
> capstone - pmaydell,mdroth,stefanha
> dtc - pmaydell,mdroth,stefanha
> edk2 - pmaydell,mdroth,stefanha
> ipxe - kraxel,lprosek
> keycodemapdb - pmaydell,mdroth,stefanha

Mirroring this on gitlab is a little silly when the primary upstream
is already on gitlab :-)

   https://gitlab.com/keycodemap/keycodemapdb

> libslirp - pmaydell,mdroth,stefanha
> meson - pmaydell,mdroth,stefanha
> openbios - pmaydell,mdroth,stefanha
> openhackware - pmaydell,mdroth,stefanha
> opensbi - <none>
> qboot - pmaydell,mdroth,stefanha
> qemu - pmaydell,mdroth,stefanha
> qemu-jeos - pmaydell,mdroth,stefanha
> QemuMacDrivers - pmaydell,mdroth,stefanha
> qemu-palcode - pmaydell,mdroth,stefanha


> qemu-stable-0.10 - jforbes,afaerber,mdroth
> qemu-stable-0.14 - jforbes,afaerber,mdroth
> qemu-stable-0.15 - jforbes,afaerber,mdroth
> qemu-stable-1.0 - jforbes,afaerber,mdroth
> qemu-stable-1.1 - jforbes,afaerber,mdroth
> qemu-stable-1.2 - jforbes,afaerber,mdroth
> qemu-stable-1.3 - jforbes,afaerber,mdroth
> qemu-stable-1.4 - jforbes,afaerber,mdroth

IIUC, the content from these is present in the main qemu.git.

Should we mark them "archived" in gitlab, so they're not listed
by default as active repos.

> qemu-web - paolo,jcody,pmaydell,mdroth,thuth
> s390-tools - pmaydell,mdroth,stefanha
> seabios - pmaydell,mdroth,stefanha
> seabios-hppa - pmaydell,mdroth,stefanha
> sgabios - paolo
> skiboot - pmaydell,mdroth,stefanha
> SLOF - pmaydell,mdroth,stefanha
> u-boot - pmaydell,mdroth,stefanha
> u-boot-sam460ex - pmaydell,mdroth,stefanha
> vbootrom - pmaydell,mdroth,stefanha
> vgabios - pmaydell,mdroth,stefanha
> 
> Quite a few of those repos are mirrors and actually don't need human
> push access.
> 
> The people who need push access are:
>  * bonzini - qemu-web
>  * mdroth - qemu-stable
>  * pmaydell - qemu
>  * rth - qemu
>  * stefanha - qemu
>  * thuth - qemu-web
> 
> Does this sound good?

Doesn't  mdrooth need  'qemu-web' access for updating the list of
releases ?

We probably ought to have more than one person with push to qemu-stable,
even if mdroth normally does it all, just to improve a bus factor.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC] Using gitlab for upstream qemu repo?

[Peter Maydell]

On Tue, 27 Oct 2020 at 14:08, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> Here are the users with commit access to qemu.org repos:

> The people who need push access are:
>  * bonzini - qemu-web
>  * mdroth - qemu-stable
>  * pmaydell - qemu
>  * rth - qemu
>  * stefanha - qemu
>  * thuth - qemu-web
>
> Does this sound good?

All the qemu-stable-* are old and presumably no longer updated.
mdroth needs access also to 'qemu' I think so as to be able
to push to the stable branches/tags in that repo.

thanks
-- PMM

Re: [RFC] Using gitlab for upstream qemu repo?

[Paolo Bonzini]

On 27/10/20 14:14, Michael Roth wrote:
> My only concern would be what the lag time might be between updates to
> qemu-web.git and the actual website update if the mirroring doesn't
> right away. Probably not a huge deal but might be good to know what the
> upper bound is if we want to verify the update process went okay.

If gitlab became the primary repo for qemu-web.git, deployment would be
done differently; either by rsyncing directly to qemu.org, or by making
www.qemu.org a proxy for qemu-project.gitlab.io/qemu.

Thanks,

Paolo

Re: [RFC] Using gitlab for upstream qemu repo?

[Peter Maydell]

On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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.

> - right now Gitlab pulls from upstream repos and qemu.org pulls from
> gitlab, but this is not true for the qemu, qemu-web and openbios
> repositories where Gitlab pulls from qemu.org and qemu.org is the main
> repository.  With this switch, all the main repositories would be on
> Gitlab and then mirrored to both qemu.org and GitHub.  Having a
> homogeneous configuration makes it easier to document what's going on.

So IIRC we decided that we wanted to do this git.qemu.org -> gitlab
switchover, but not during the 5.2 release. 5.2 is now out the door,
so what's the next step to do the changeover? Now seems like a good
time to do it so we can be happy we've dealt with any snags well
before we get towards softfreeze.

thanks
-- PMM

Re: [RFC] Using gitlab for upstream qemu repo?

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

On Tue, Jan 05, 2021 at 02:12:59PM +0000, Peter Maydell wrote:
> On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 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.
> 
> > - right now Gitlab pulls from upstream repos and qemu.org pulls from
> > gitlab, but this is not true for the qemu, qemu-web and openbios
> > repositories where Gitlab pulls from qemu.org and qemu.org is the main
> > repository.  With this switch, all the main repositories would be on
> > Gitlab and then mirrored to both qemu.org and GitHub.  Having a
> > homogeneous configuration makes it easier to document what's going on.
> 
> So IIRC we decided that we wanted to do this git.qemu.org -> gitlab
> switchover, but not during the 5.2 release. 5.2 is now out the door,
> so what's the next step to do the changeover? Now seems like a good
> time to do it so we can be happy we've dealt with any snags well
> before we get towards softfreeze.

Yes, let's do this now.

I will send a patch to point .gitmodules at GitLab. In the process of
doing this I noticed sgabios.git is not yet mirrored on GitLab. After I
create that repo (and any other missing repos) I will send a qemu.git
patch series that references the GitLab repos instead of qemu.org repos.

We can perform the mirroring direction switch that Paolo described above
independently.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC] Using gitlab for upstream qemu repo?

[Paolo Bonzini]

On 11/01/21 10:57, Stefan Hajnoczi wrote:
> I will send a patch to point .gitmodules at GitLab. In the process of
> doing this I noticed sgabios.git is not yet mirrored on GitLab. After I
> create that repo (and any other missing repos) I will send a qemu.git
> patch series that references the GitLab repos instead of qemu.org repos.
> 
> We can perform the mirroring direction switch that Paolo described above
> independently.

So we have five steps:

1) pointing .gitmodules to GitLab

2) reversing mirroring so that GitLab pushes to qemu.git and not vice versa

3) adding a mirroring rule like (2) for qemu.git and qemu-web.git

4) moving qemu-web.git deployment from qemu.org hooks to GitLab CI.

I can take care of (2), and also (3) once we know it works well.  Once 
Daniel's qemu-web.git CI work lands we can also do (4).

Paolo