[Spice-devel] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

Christophe de Dinechin cdupontd at redhat.com
Thu Jul 27 13:15:33 UTC 2017


> On 27 Jul 2017, at 15:07, Frediano Ziglio <fziglio at redhat.com> wrote:
> 
> On 27 Jul 2017, at 12:39, Christophe Fergeau <cfergeau at redhat.com <mailto:cfergeau at redhat.com>> wrote:
> 
> On Thu, Jul 27, 2017 at 11:54:08AM +0200, Victor Toso wrote:
> On Mon, Jul 24, 2017 at 10:47:34AM -0400, Frediano Ziglio wrote:
> Not really familiar with GitLab merge requests but on GitHub they
> remain open till closed so this would help with old ones.
> The big change on moving to full PR is the way of commenting patches.
> Unless PR are just used for tracking and are replicated to ML but
> maybe is hard to keep them consistent. I think is possible to configure
> PRs to send changes to ML. This would make the history persistent on
> the ML.
> 
> Could we try for a period and see how does it go?
> 
> +1, but how should we approach that? I think we need to move from
> freedesktop to either gitlab or github first otherwise we can get
> confused on what's going on.
> 
> 
> Just to be sure, you are both suggesting switching to pull requests, and
> doing the reviews in gitlab web UI?
> 
> Not me. Reviewing by mail is fine with me.
> 
> Actually, Im concerned that if we switch to PR/MR, then some comments
> will end up being made only there, which is why I asked if there was a
> way to forward these comments to the mailing list. I believe this
> is possible from the group administration (its certainly possible
> for individual accounts on gitlab).
> 
> 
> The initial problem is that some reviews are not done in a timely
> manner. Being able to easily get a list of pending reviews was brought
> forward as a potential solution to this problem, and apparently, you
> both think that switching from email based reviews to a web based review
> system would help in getting more reviews faster? (iow, it would make
> you more efficient at reviewing code, and you vastly prefer that over
> email).
> 
> No, that’s not correct (at least for me). The review itself can happen over mail,
> what I find inefficient is:
> 
> a) to get the list of things to review, and
> b) to get a working version of the code after patching
> 
> For a), email is good to notify you of recent reviews posted. But searching
> through e-mail for unreviewed stuff is not easy. Do you have a good trick for that?
> 
> For b), Im not talking about git am. You may not realize that just
> figuring out which of our 17 repositories (not including personal
> ones) some particular patch applies to is not always obvious.
> 
> Im pretty sure this is not so much of a problem when you have worked
> longer on the project, so I am bringing that up precisely because
> Im still fresh enough to remember this being an issue.
> 
> 
> 
> I'm not necessarily opposed to trying things out, I'm just trying to get
> a clear view of what we are expecting to get out of the change.
> 
> First things first, if we want to try MR/PR, we should switch to gitlab
> as the primary. I understand there was a desire to do that also because
> freedesktop user creation was slow.
> 
> Would this be a valid first step?
> 
> 
> Christophe
> There's already https://gitlab.com/spice/spice <https://gitlab.com/spice/spice>

Yes, but it’s a clone of freedesktop instead of the other way round. So as I pointed out in an earlier email, if we enable merge requests there, we may end up with merge commits, and then a push from freeedesktop will run into trouble.

So if we want to try MR on gitlab.com, then we need gitlab to be primary and freedesktop to be the mirror, I believe.


Christophe



> 
> Frediano
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170727/a0a18300/attachment-0001.html>


More information about the Spice-devel mailing list