[Spice-devel] Using GitLab

[Derek Lesho]

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 
<https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#create-new-merge-requests-by-email> 
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 <https://github.com/Guy1524/glmlbridge> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20191101/cafa413e/attachment.html>