[Spice-devel] Using GitLab

[Frediano Ziglio]

> Hi,

> On 11/1/19 6:48 AM, Victor Toso wrote:

> > Hi,
> 

> > On Thu, Oct 31, 2019 at 11:47:56AM -0500, Derek Lesho wrote:
> 

> > > On 10/31/19 11:04 AM, Victor Toso wrote:
> > 
> 

> > > > Hi,
> > > 
> > 
> 

> > > > On Thu, Oct 31, 2019 at 10:56:59AM -0500, Jeremy White wrote:
> > > 
> > 
> 

> > > > > Hey Victor,
> > > > 
> > > 
> > 
> 

> > > > > On 10/31/19 10:46 AM, Victor Toso wrote:
> > > > 
> > > 
> > 
> 

> > > > > > Hi list,
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > You might note that the Gitlab activity will increase a bit
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > from now on, hopefully. It was agreed within some SPICE
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > collaborators to give a serious try on using this
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > infrastructure that is available to us.
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > One potential great change and challenge is the usage of
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > merge requests in oppose to patch series over mailing list. I
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > hope the benefits outweigh the downsides in the long run.
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > Derek has been working on a utility to integrate GitLab and a
> > > > 
> > > 
> > 
> 
> > > > > mailing list, for experimentation by Wine.
> > > > 
> > > 
> > 
> 

> > > > > He's just gotten to the point of being ready to try a proof of
> > > > 
> > > 
> > 
> 
> > > > > concept.
> > > > 
> > > 
> > 
> 
> > > > > Would you guys be interested in this?
> > > > 
> > > 
> > 
> 

> > > > What does it do exactly?
> > > 
> > 
> 

> > > > Cheers,
> > > 
> > 
> 
> > > > Victor
> > > 
> > 
> 

> > > Hi Victor,
> > 
> 

> > > The bridge sends all the commits from merge-requests in patch
> > 
> 
> > > form to the mailing list, as well as any comments the MR
> > 
> 
> > > receives.
> > 
> 

> > Cool. It works with specific user in gitlab as sender? This seems
> 
> > nice, somewhat similar to spice-commits. I'd say great to have
> 
> > it.
> 

> The bot actually uses the Gitlab API to receive merge-request events, and
> sends the emails itself via smtplib.

> > > It also creates MRs from PATCH submissions to the mailing
> > 
> 
> > > list.
> > 
> 

> > Also seems fine but can be confusing. In regards to ownership,
> 
> > the sender must have a Gitlab account or a generic user creates
> 
> > the MR?
> 

> A generic user creates the merge request.

> > > The goal with this is to ensure the developers who are
> > 
> 
> > > accustomed to using either system aren't isolated from
> > 
> 
> > > developers using the other.  Optionally, the bridge can be
> > 
> 
> > > configured to allow people to respond to the generated MRs and
> > 
> 
> > > patch-sets, however this is disabled by default since it can be
> > 
> 
> > > confusing based on the differences between email threads and
> > 
> 
> > > GitLab discussions.
> > 
> 

> > Personally, the patch review being done in Gitlab would be best
> 
> > also for the sake of integration around it (e.g: one topic of
> 
> > review is solved you have the 'resolve thread', the diff between
> 
> > versions, probably more).
> 

> > Having the comments of reviews being sent to mailing-list can
> 
> > also be confusing if replying to that in email does not get
> 
> > propagated back to Gitlab but if explicit says something like
> 
> > "don't reply", it looks great as mentioned above.
> 

> When bidirectional communication is disabled, the sent mail does specify not
> to reply. However, right now this only occurs on merge requests not
> generated from a mailing-list submission.
> If you want all review to occur on Gitlab, you may instead want to disable
> the part of the bridge that reads email and instead point mailing-list users
> to this for submitting their patches. At that point, the bridge would just
> be used to send all the merge request activity to the mailing list.

> > But this is all just my opnion. The rationale for using more
> 
> > Gitlab is for several reasons. If you like the idea and using
> 
> > this seems a must, I'm all in to give it a try :)
> 

> I completely agree with your reasons to use Gitlab more, the reason my bridge
> includes the functionality to accept communication on the mailing list is
> for devs who are used to that workflow. If nobody in your community is
> interested in that functionality, I see no reason to include it.
> The unfinished code is currently on Github (ironically), and is still quite
> messy (littered with TODOs and debug prints). If you're still interested,
> I'll clean up the project and try to improve the documentation over the
> weekend so you can give it a shot.

> > Cheers,
> 
> > Victor
> 

> -Derek

I have contrasting opinions about it.

The idea to be free to use ML or MR look amazing.

If we  decide to prefer Gitlab MR having a tool that try to create MR from
e-mail where should we continue to discuss? On ML or Gitlab? It looks quite
confusing, the workflow would become quite complicated.
P
otentially there will be quite some more e-mails on the ML making
"manual" e-mail less visible which is bad.

There's another tool/configuration to maintain.

The mail allows quite a lot of flexibility, would happen on a very complex
reply to a MR opened directly in Gitlab?

If we decide to go to a sort of backup/history on a ML I would prefer to
have a separate ML where everything is in CC to it (a bit like main Linux
Kernel ML although this can also be used as normal one).

Frediano