The main problem for me is that I want to have the patch merged asap, to be able to test/resolve issues of some other patches in combination with this one. That's why I just merge that without rebase-pipeline completion.
Speaking truly, I'm not very happy with our 'always fast-forward merge' policy [0], but given GitLab doesn't provide an option to switch policy on-the-fly, it should be fine for now. [0] - this policy is good for small patches, but for bigger patchset I would prefer to see an explicit merge commit On Tue, Dec 19, 2023 at 10:25 AM Ben Cooksley <bcooks...@kde.org> wrote: > On Tue, Dec 19, 2023 at 10:16 PM Dmitry Kazakov <dimul...@gmail.com> > wrote: > >> Hi, Ben! >> >> I think we have kind of forgotten about that. I usually build the MRs >> locally or check if the pipeline has succeeded for the current revision, >> then I just "rebase without pipeline" and do the merge. It might be that I >> should use the merge service for that, I'm not sure... >> > > That is fine. Given it doesn't seem to be too well loved i'm going to > decommission the service. > > The initial issues we had with it's reliability had been resolved however > I think that happened not too long before people stopped using it. > > Cheers, > Ben > > >> >> On Sat, Dec 16, 2023 at 2:41 AM Ben Cooksley <bcooks...@kde.org> wrote: >> >>> Hi all, >>> >>> I've just been reviewing services we're looking after and while doing so >>> have noticed that Marge Bot (invent.kde.org/merge-service) doesn't seem >>> to have done anything for 4 months. >>> >>> As the two projects with it enabled, is this something you're still >>> using as it doesn't look like it. >>> >>> Thanks, >>> Ben >>> >> >> >> -- >> Dmitry Kazakov >> > -- Dmitry Kazakov
