[Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Daniel Vetter]

Hi Laurent,

On Mon, Sep 10, 2018 at 11:33 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> 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