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 BD733113B for ; Mon, 10 Sep 2018 17:11:00 +0000 (UTC) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 354677D9 for ; Mon, 10 Sep 2018 17:11:00 +0000 (UTC) Received: by mail-io0-f170.google.com with SMTP id q5-v6so1266789iop.3 for ; Mon, 10 Sep 2018 10:11:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Daniel Vetter Date: Mon, 10 Sep 2018 19:10:58 +0200 Message-ID: To: Olof Johansson 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: , On Mon, Sep 10, 2018 at 6:39 PM, Olof Johansson wrote: > On Mon, Sep 10, 2018 at 8:31 AM, 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. > > Agreed, I probably won't be able to keep up with this whole thread > this week due to $job, but a few stray comments: > >> 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 :-) > > I'm not interested in standing up and talking about how Arnd and I > handle things right now, but what I would be really interested in > talking about is where we still have chafing, where things don't > actually work great (Linus might be happy, but we're definitely in a > spot where we could simplify life for _us_ quite a bit). > > I'm super excited to hear a bit about the _actual_ plans of gitlab > move. As mentioned, not a visionary keynote, but others also talking > about what they're looking at to fix their current pain points. It's the topic in the other thread, so hooray for chaos, but don't worry: I plan to make the talk as concrete as possible for a "we're planning this" talk. Rought structure I have in mind: - short overview of why fd.o admins want to switch and why, with a bit of history on how drm is influenced from both kernel and userspace alike. - going through our current pain points, and how we think some gitlab concepts could help. I hope that a bunch of things will be concrete already here, using some of our userspace repos like the test-suite as guinea pigs. - the epic long lists of issues and infrastructure we're seeing already in case we want to actually follow through on any of this. Plus a request for "what did we miss?". It's definitely not going to be your inspirational keynote thing about how awesome community management is, ks is the wrong place for that :-) Cheers, Daniel > For us on arm-soc, we've gotten a bit better at reducing our overhead, > but the bulk of material coming in these days tends to be a no-op from > us (just figure out that it merges, that we have handshakes with any > external dependencies or shared branches, and pick it up). We have > some submaintainers who need more work, and we pay closer attention to > and have more feedback, but reducing the overhead for some of the > others by letting them cross-review and merge themselves would be > useful. > > I'm also starting to get mildly annoyed by the single-patch pull > requests that we sometimes get. In some ways, applying patches are > easier, not harder. For those, the model where "cherry pick when > merging" in common code review tools would work really well. > >> And if nothing changed, no new groups I think think we should table >> this right away. > > I really want to talk about this, but if there isn't enough interest > from others, we could just do it in a hallway. But I think the topic > is on point for the maintainer summit. > > > -Olof -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch