> 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel