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 4BC67F21 for ; Wed, 12 Sep 2018 20:05:22 +0000 (UTC) Received: from mail-it0-f67.google.com (mail-it0-f67.google.com [209.85.214.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BC577C6 for ; Wed, 12 Sep 2018 20:05:21 +0000 (UTC) Received: by mail-it0-f67.google.com with SMTP id j81-v6so4833414ite.0 for ; Wed, 12 Sep 2018 13:05:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180912185949.GC25894@wrath> References: <20180912185949.GC25894@wrath> From: Daniel Vetter Date: Wed, 12 Sep 2018 22:05:19 +0200 Message-ID: To: Darren Hart Content-Type: text/plain; charset="UTF-8" Cc: Andy Shevchenko , ksummit Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart wrote: > On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote: >> I need to split this up, otherwise I'll get lost on the different >> sub-topics. I'll start with the easy ones. >> >> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds >> wrote: >> >> Specific topics I'm interested in: >> >> - New experiments in group maintainership, and sharing lessons learned >> >> in general. >> > >> > I think that's good. But again, partly because these kinds of subjects >> > tend to devolve into too much of a generic overview, may I suggest >> > again trying to make things very concrete. >> > >> > For example, talk about the actual tools you use. Make it tangible. A >> > couple of years ago the ARM people talked about the way they split >> > their time to avoid stepping on each other (both in timezones, but >> > also in how they pass the baton around in general, in addition to >> > using branches). >> > >> > And yes, a lot of it probably ends up being "we didn't actually make >> > this official or write it up, but we worked enough together that we >> > ended up doing XYZ". That's fine. That's how real flows develop. With >> > discussion of what the problems were, and what this solved. >> > >> > In other words, make it down to earth. Not the "visionary keynote", >> > but the "this is the everyday flow". >> >> Yup, fully agreed. We don't need another overview over group >> maintainer ship. Also I don't think an update from arm-soc/tip or drm >> is interesting either. I think only if there's a new group/subsystem >> trying this out, with all the nitty-gritty details of "this totally >> blew up in our faces" and "this worked shockingly well" and "here we >> need to improve still, we're not happy" is what I'm looking for. >> Without those details there's nothing really to learn, beyond just >> rehashing one of the old discussions. I guess I should have put more >> emphasis on _new_ experiments :-) >> >> And if nothing changed, no new groups I think think we should table >> this right away. > > For x86 platform drivers, Andy and I raised a few issues a while back > regarding some of the new tests added to -next which broke our process. > We discussed those in some detail back then, but I think the general > case that much of our process seems to assume a single maintainer. We > have put some fences in place to work around this, but they are rather > fragile. We don't have a combined testing branch anymore (but I think we > should). If we catch a bug in a commit far enough back in the history of > a "published" branch that we have both committed on top of it, it's a > major logistical pain to get back to good. > > Regarding tooling, Andy and I have documented our process and shared our > tooling which has evolved to try and prevent human error. I believe DRM > has something even more evolved. > > https://github.com/dvhart/pdx86-tools Hm, the gen-config scrips looks like a really neat idea. Atm we manually maintain some configs for all the drm drivers, but this is much better I think. Next step up would be to double-check that make oldconfig didn't disable any of the options we want. I think this would even be useful in upstream, if you can give it Kconfig files or entire directories it's supposed to search for, and enable everything in there. Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig seems to do this, including enabling (all?) dependencies you need. > For us, most of the patches we receive are one-offs to fix a specific > laptop. I expect these could work just fine from a GitHub workflow > and would help bridge the gap between all the people filing bugs in > bugzilla and the people submitting patches to LKML. With something like > GitHub, I think it's possible more of the bug reporters would consider > submitting fixes - even if Andy and I had to do a bit more work to get > them merged. Get travis CI to run the checks for you and dump results into pull requests. That's at least the plan we have on the gitlab side. Everytime you see the same screw up 10 times, you add another check to your scipts. I haven't tried whether this works in practices for kernel stuff, and how much work it is. But the concept is used to great success in other communities. Think instead of just documentation where you have to help new contributors to find all the bits (they're there, but the kernel docs are huge, so finding everything is tricky), you have interactive docs where bots walk first contributors through everything. E.g. forgot sob line -> bot gives you a link to the docs where sob is explained. Some of these could be upstreamed to checkpatch I think, but you'd probably still need some glue to extract the links/help texts and put it at the right place in the pull request. E.g. anything coding style related should ideally be a review comment added at exactly the right spot. > The question here is: how do we ensure patches submitted via > github/gitlab are also sent to LKML and to bridge the reviewers there > with the authors. Some kind of a bridge/gateway seems doable, but I'd > want this to be a broader effort than just our subsystem to make it > worthwhile - as well as socialize it sufficiently that the initial > glitches are anticipated and dealt with constructively. There are gateways (afaick), but generally those gateways are not enthusiastic about spamming random people you just add to the Cc: list of a patch. Definitely not on github - github doesn't want to be a spam relay. On self-hosted stuff like gitlab this might be possible, but I've honestly not tried this out yet. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch