Hi,
On 11/1/19 6:48 AM, Victor Toso wrote:
The bot actually uses the Gitlab API to receive merge-request events, and sends the emails itself via smtplib.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, VictorHi 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.
A generic user creates the merge request.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?
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.
-DerekCheers, Victor
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel