From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 51FE6F00 for ; Mon, 10 Sep 2018 22:45:00 +0000 (UTC) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5CAF6102 for ; Mon, 10 Sep 2018 22:44:59 +0000 (UTC) Received: by mail-io0-f179.google.com with SMTP id v14-v6so2044988iob.4 for ; Mon, 10 Sep 2018 15:44:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <2019489.6joTqyUi4Z@avalon> References: <8412864.7ztUKcXNNC@avalon> <2019489.6joTqyUi4Z@avalon> From: Daniel Vetter Date: Tue, 11 Sep 2018 00:44:57 +0200 Message-ID: To: Laurent Pinchart Content-Type: text/plain; charset="UTF-8" Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Laurent, On Mon, Sep 10, 2018 at 11:33 PM, Laurent Pinchart wrote: > On Monday, 10 September 2018 23:55:22 EEST Daniel Vetter wrote: >> On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart wrote: >> > On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote: >> >> My goal at least with this is much more in figuring out new workflows, >> >> and running a pile of experiments. As mentioned, we don't yet even >> >> have a plan for all this, the goal here is to spark some discussions >> >> and figure out whether maybe others want to come along for the ride. >> > >> > I recently had to deal with a new bugs and tasks management tool that was >> > developed in-house by a customer of mine. The tool was presented to us in >> > its first RFC version (and in source code form, which is very nice), with >> > very few implemented features, and without telling us what process it was >> > supposed to support. When I inquired I got told that the process hasn't >> > been taken into consideration to develop the tool, and that it would just >> > come into existence as a result of the tool. Needless to say, it was hard >> > for me to review the code, without knowing what it was supposed to do. >> > >> > I don't claim we're going to that extreme, but I believe it would be >> > useful to detail the problems we have in order to find solutions, instead >> > of proposing solutions and then trying to retrofit them to problems. >> >> We're definitely starting with some pain points, and don't do this >> gitlab thing as an a solution looking desperately for a problem. With >> my intel hat on there's a few main ones: >> >> - CI integration with patchwork is a pain, for developers, maintainers >> and CI people all alike. I plan to do some slides on what exactly >> sucks and what gitlab is doing better, but I'm just not quite there >> yet. As mentioned somewhere else, ideally we'd have the full demo >> ready for LPC using the userspace igt gpu tests repo. > > I'm interested in knowing whether you think this is due to the concept behind > patchwork, or to the current implementation. I like the idea of patchwork as a > tool that assists an email-based workflow in areas where emails are too > limited. I think we could do much more, and I believe we could achieve a good > result, while keeping the same philosophy. The problem with patchwork is that it's a sidelined add-on. It's not in your face when doing a normal contribution. Our patchwork tries to fix that by sending replies to the mailing lists, but to avoid spam, it only does that when CI is done. While it's still crunching through your series you have to know a magic link where you can watch it go through it's backlog. We could update more often, but people already complain about the spam our CI produces. gitlab otoh gives you a neat status indicator, and direct links where you can watch it do its thing live. All neatly integrated into the one merge request interface. Now if you've never done CI before, you'll probably go meh on this. But the trick in making CI really effective is to make it about as addictive as a slot machine. Instant gratification and quick results is absolutely key, and developers want to watch it do its things. The more you can give them that, the more your developers will care about CI results (the green checkmark quickly starts to look like candy in your eyes), and the less maintainers have to check this themselves. There's a bunch of other things, like integration with the git side of things (you can block a merge if it fails CI). So the above is the contributor/maintainer perspective. The CI perspective is that the guy maintaining patchwork for us would like to do more useful things than maintain a pile of duct-tape :-) The fully integrated REST api of gitlab is pretty good catnip for devops types. >> - First contributor flow can be (if done correctly) so much more fun >> than mailing lists. There's been a bit of chatting on this already in >> this thread. > > I recall lots of frustration from regular contributors during a discussion > about kernel maintainership, where many considered that we went to extremes to > help first contributors, while very little was done to address the issues of > regular contributors. Let's keep both sides in mind, otherwise we'll end up > moving our development process to instagram because, you know, that's where > the new generation is, people don't use e-mails anymore. First contributors aren't your antagonists, they're your canaries for bad process. Long timers just suck it up (or don't even see it anymore), first timers don't even bother because the hurdle is insurmountable. And yes sometimes it's the other way round, were problems really show up at scale, but only hurt a bit on the very first patch. The goal, at least mine, is to make it easier for everyone, at all levels of experience&contribution. >> - Tracking patch series as they evolve from RFC to final reviewed >> version. Patchwork, even with all the extensions we have since years >> in the fd.o one, just can't cope. This might be an artifact of our >> group maintainership + committer model, I think for single maintainer >> patchwork does work a bit better. This is the "patches on mailing >> lists don't scale, I have the T-shirt" problem Linus already >> mentioned. Our PMs/managers also don't like that they can't keep track >> of what the fairly big drm/i915 team is doing :-) > > I've pointed out the issue that patch series don't always have fixed > boundaries in another reply to this thread, and I think that's the core reason > why this problem isn't solvable. We should have a working solution for the > common case though, and I fail to see why a tool like patchwork couldn't do it > (not claiming it does at the moment of course). gitlab (or well anything with a concept like pull requests) makes the 90% so much easier. And it doesn't take more work for contributors if you set things up right - it's just a git push instead of a git send-email. At least after initial setup is done. And at least in a corporate environment (and I kinda have to care about that) gitlab wins on the initial setup front hands down against email. gitlab only needs https (even for git push/pull), and coproporate firewalls are pretty ok with https. They are not ok with smtp, like at all. And the amount of time we spend debugging random git send-email setup issues is epic. There's alwasy going to be the thing where you have to split up a patch series into multiple patch series, or merge a few. And then you need to manually add links to the other/past discussions in either system. The gitlab plaintext syntax for auto-closing/linking other issues and merge requests is pretty good, whereas emails it's all colating web links and msg-id, which at least I personally fine a chore and so almost never bother with. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch