qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [RFC] Using gitlab for upstream qemu repo?
Date: Fri, 23 Oct 2020 09:51:31 +0100	[thread overview]
Message-ID: <20201023085131.GC445638@redhat.com> (raw)
In-Reply-To: <9f6c63c6-599b-ac15-42e2-b9c1991fc7ee@redhat.com>

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



  parent reply	other threads:[~2020-10-23  8:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22 16:47 [RFC] Using gitlab for upstream qemu repo? Paolo Bonzini
2020-10-22 17:24 ` Eric Blake
2020-10-23  7:37   ` Gerd Hoffmann
2020-10-23  8:51   ` Daniel P. Berrangé [this message]
2020-10-23 13:41     ` Stefan Hajnoczi
2020-10-23  9:37   ` Paolo Bonzini
2020-10-23  8:44 ` Daniel P. Berrangé
2020-10-23 13:41 ` Stefan Hajnoczi
2020-10-26 11:04 ` Peter Maydell
2020-10-27 13:14   ` Michael Roth
2020-10-27 18:48     ` Paolo Bonzini
2020-10-27 14:08   ` Stefan Hajnoczi
2020-10-27 14:20     ` Daniel P. Berrangé
2020-10-27 14:32     ` Peter Maydell
2021-01-05 14:12 ` Peter Maydell
2021-01-11  9:57   ` Stefan Hajnoczi
2021-01-11 11:02     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201023085131.GC445638@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=eblake@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).