Investigating GitLab

I don't think some of the things mentioned in this article about Patchwork are entirely accurate.

It's not read-only and it can be an accurate state of the list, updated when patches are merged, under review, superceded, rejected etc. Take a look at linuxppc-dev, for instance: http://patchwork.ozlabs.org/project/linuxppc-dev/list/

To be easy for maintainers, this requires things like git hooks and magic to sync with Patchwork, which is non-trivial, but once set up it is good.

I don't think test results are buried in Patchwork either. It can be if you're only talking about things like 0-day email replies to patches, but you can send test results directly to Patchwork and have them show up in both the patch list (as a Success/Warning/Failure count) but also listed at the top of the patch when you inspect it. Again, go to an individual patch on the linuxppc-dev list and have a look at the checks, and you can filter patches based on author or whatever you wanted.

Patchwork also supports tagging in the API so you could filter based on what branches patches are intended for, if you wanted.

I'm not going to try and argue against moving some kernel development away from mailing lists because obviously you do get a lot of nice things with a more modern solution like GitLab, but a *lot* of the niceties you get from doing that you can have without changing the way your developers do things.

(disclaimer: I run the CI system that sends things to Patchwork on linuxppc-dev and some other lists, and am plugging https://github.com/ruscur/snowpatch/ if you want to automate running tests on incoming patches and sending the results to Patchwork)