Re: [RFC] Using gitlab for upstream qemu repo?
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
Re: [RFC] Using gitlab for upstream qemu repo?
On Tue, Jan 05, 2021 at 02:12:59PM +, Peter Maydell wrote: > On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini 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 signature.asc Description: PGP signature
Re: [RFC] Using gitlab for upstream qemu repo?
On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini 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?
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?
On Tue, Oct 27, 2020 at 02:08:18PM +, Stefan Hajnoczi wrote: > On Mon, Oct 26, 2020 at 11:04:06AM +, Peter Maydell wrote: > > On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini 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 - > 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?
On Tue, 27 Oct 2020 at 14:08, Stefan Hajnoczi 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?
On Mon, Oct 26, 2020 at 11:04:06AM +, Peter Maydell wrote: > On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini 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 - 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 signature.asc Description: PGP signature
Re: [RFC] Using gitlab for upstream qemu repo?
On Mon, Oct 26, 2020 at 11:04:06AM +, Peter Maydell wrote: > On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini 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?
On Thu, 22 Oct 2020 at 17:48, Paolo Bonzini 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?
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 signature.asc Description: PGP signature
Re: [RFC] Using gitlab for upstream qemu repo?
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 signature.asc Description: PGP signature
Re: [RFC] Using gitlab for upstream qemu repo?
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?
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?
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?
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?
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
[RFC] Using gitlab for upstream qemu repo?
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
