* [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance @ 2018-09-10 8:59 Daniel Vetter 2018-09-10 14:53 ` Linus Torvalds 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 8:59 UTC (permalink / raw) To: ksummit Hi all, I've read Laura's recent blog post on community management in the linux kernel and want to pick it up: https://www.labbott.name/blog/2018/09/04/kernel-community-management/ I think for pratical reasons (the linux kernel is huge) focusing on subsystems is more useful, at least in the short term. Much easier to experiment with new things in smaller groups. That's why I added "subsystem governance". If there's enough interest on specific topics we could schedule some BOF sessions, otherwise just hallway track with interested parties. Specific topics I'm interested in: - New experiments in group maintainership, and sharing lessons learned in general. - Assuming it gets accepted I think my LPC talk on "migrating to gitlab" will raise some questions, and probably overflow into hallway track or a BOF session. - I've held a somewhat controversially received talk earlier this year. I'm happy to do a Q&A on that, if there's interest. But I'm open to anything else really on the larger topic of community mangement. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 8:59 [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance Daniel Vetter @ 2018-09-10 14:53 ` Linus Torvalds 2018-09-10 15:08 ` James Bottomley ` (5 more replies) 0 siblings, 6 replies; 162+ messages in thread From: Linus Torvalds @ 2018-09-10 14:53 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > I think for pratical reasons (the linux kernel is huge) focusing on > subsystems is more useful, at least in the short term. Much easier to > experiment with new things in smaller groups. I think that realistically, it's never going to be anything *but* subsystem-specific, not just because the kernel is huge. There are simply often very different concerns. An individual filesystem can be a big project, and people work on filesystems for decades. They can get quite complex indeed. But at the same time, an individual filesystem just doesn't tend to *impact* other things. Sure, we may end up adding features to the VM or the VFS layer to make it possible for it to do some particular thing, and we may end up having lots of common code that a lot of filesystems end up sharing, but in a very real sense, it is its own _mostly_ independent thing, and what happens inside the community for that filesystem doesn't tend to much affect anybody else. Same goes for a lot of drivers. Yes, they have connections to the outside, but what happens in one driver seldom affects anything else. Equally importantly, filesystem changes can generally be tested with a fairly targeted test-suite. When you make changes to one filesystem, you need to test only _that_ filesystem. The same _tends_ to be true for drivers too, although there testing can be "interesting" because of the hardware dependency - a single driver often covers a few tens (to a few hundred) different hardware implementations. But the changes still don't tend to affect *other* devices. But things change once you start going up from individual filesystems or drivers to a common layer. Making changes to a common layer is simply _fundamentally_ way more painful. Sure, part of the pain is that now you have to convert all the filesystems or drivers that depended on that common layer to the new changes, but a large part is simply that now the changes affect many different kinds of filesystems or drivers, and testing is *much* harder. You obviously see that with the whole drm layer (example: atomic modesetting). That's still a fairly small set of different drivers (small in number, not in code-size), and it already causes issues. At the other end of the spectrum, some of the most painful changes we've ever done have basically gone across *all* drivers, and caused untold bugs for the better part of a decade. I'm thinking of all the power management work we did back ten+ years ago. The VM people (and some other groups - the scheduler comes to mind) have had a different kind of issue entirely: not that the kernel has tons of "sub-drivers" that depend on them - although that obviously is true in a very real sense for any memory allocator etc - but simply that there are lots of different loads. In a filesystem or a driver, you can have a test-suite for correct behavior, but the behavior is largely the same. When it comes to VM or scheduler, the problem is that you have different loads, and performing well on one load does not mean at all that you do well on another. We had a few years when people were pushing scheduler rchanges without really appreciating that "your load isn't everybody elses load" issue. In contrast, in drivers and filesystems, things are usually more black-and-white wrt "does this work well". Yes, yes, you have latency vs throughput issues etc, and you might have some scalability issues with per-cpu queues etc, but at the individual driver level, those kinds of concerns tend to not dominate. You want a stress-test setup for testing, but you don't need to worry too much about lots of crazy users. So different areas of the kernel just tend to have different concerns. You can allow people to work more freely on a driver that doesn't affect other things than on something that possibly screws over a lot of other developers. But if we find "models that work", maybe we can at least have processes that look a bit more like each other, even across subsystems. > That's why I added > "subsystem governance". If there's enough interest on specific topics > we could schedule some BOF sessions, otherwise just hallway track with > interested parties. So what I think would be good is to not talk about some nebulous "community management", but talk about very specific and very real examples of actual technical problems. Partly exactly *because* I think the areas are not all the same, and the friction points are likely *between* these areas that may even have really good reasons to act differently, and mostly they are independent and have little interaction, but then when interaction happens, things don't work well. IOW, if we have the top-level maintainers around, we should have a gripe-fest where people come in and say "Hey, you, look, this *particular* problem has been around for a year now, there's a patch, why did it not get applied"? Don't make it about some nebulous "we could do better as a community". Instead, make it about some very *particular* issue where the process failed. Make it something concrete and practical. "Look, this patch took a year to get in, for no good reason". Or "Look, here's a feature that I *tried* to get accepted for a month, nothing happened, so I gave up". And if we have a few of those, maybe we can see a pattern, and perhaps even come up with some suggestion on how to fix some flow. And if people can't come up with particular examples, I don't think it's much worth discussing. At that point it's not productive. We need to name names, show patches, and talk about exactly where and how something broke down. > 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". > - Assuming it gets accepted I think my LPC talk on "migrating to > gitlab" will raise some questions, and probably overflow into hallway > track or a BOF session. I've not used gitlab personally, but I *have* used github for a much smaller project. I have to say, the random and relaxed model is enjoyable. I can see how somebody coming from that, then finds the strict kernel rules (and _different_ rules for different parts) off-putting and confusing. At the same time, I have to say that people need to keep in mind that the kernel is *different*. We're not a small project with five developers that isn't all that critical. Some of our off-putting development models are there for a very very good reason. I think a lot of people who find the kernel unfriendly just don't appreciate that part. The kernel used to be pretty free-wheeling too. 20+ years ago. And I still hate how github ends up making it really really easy to make horribly bad commit messages, and it encourages a "just rebase on top of the integration branch" model, and I do not believe that it would ever work for the kernel at large. Too much room for chaos. BUT. I do think it's still instructive to look at how those "fun small projects" work. Having the whole web interface and a more relaxed setup is a good thing. And it's probably *better* than the strict rules when you don't really need those strict rules. So I do believe that it could work for a subsystem. Because "too much room for chaos" ends up being nice when you don't want to worry about the proper channels etc. For example, we've had the "trivial tree", which tends to be a really thankless project, that might well be managed way more easily by just having a random tree that lots of people can commit to, and we could even encourage the github (gitlab?) model of random non-kernel people just sending their random trees to it, and have then the group of committers be able to merge the changes (and at least on github, the default merge is just a fast-forward, so it actually acts more like a patch queue than a git tree). And the reason I mention the trivial tree is not because the trivial tree itself is all that interesting or because I'd like to belittle that model ("that will only work for trivial unimportant stuff"), but because it might be a good area to experiment in, and a way to get people used to the flow. Because if somebody is willing to every once in a while look at trivial tree pull requests and merge them to the trivial tree, maybe that person will start using the same flow for their "real" work. And I do think that "patches by email" doesn't scale. I've been there, done that, and I got the T-shirt. I used tools that some people absolutely hated to get out of that rat-hole. When that failed, I had to write my own. So I very much do think that email doesn't really work at scale. But I know the kernel people who still do real development (as opposed to me) work that way. So let me suggest a topic for the maintainer summit: "Live without email - possible?" just to get that ball rolling Linus ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 14:53 ` Linus Torvalds @ 2018-09-10 15:08 ` James Bottomley 2018-09-10 15:10 ` Linus Torvalds 2018-09-10 15:13 ` Jiri Kosina 2018-09-10 15:31 ` Daniel Vetter ` (4 subsequent siblings) 5 siblings, 2 replies; 162+ messages in thread From: James Bottomley @ 2018-09-10 15:08 UTC (permalink / raw) To: Linus Torvalds, Daniel Vetter; +Cc: ksummit On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: > "Live without email - possible?" Can I propose one small alteration to the topic: "Patches without Email - Possible?" The reason is I've had too much experience with other open source projects who religiously oppose email based interaction (some of them because the kernel uses it) and have seen the amount of difficulty and friction it causes and I really don't think we want to go down that exclusionary road. I think we always need a way of accepting patches by email because it's the easiest communication mechanism for people who aren't contributors. However, I think we could discuss not having email for our main workflows. Some issues this brings up that various other communities solve in different ways 1. How do reviews happen? Non email projects tend to have only one review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do we want to pick a technology or allow multiple? I don't think this is kernel wide, it could be a sybsystem choice. 2. Do we want to look at other review concepts like the core reviewers, since reviewers will now at least need accounts on whatever system it is ... it could finally be the way we give proper credit to reviewers. 3. Pull requests to Linus ... what technology do you want to choose? Note we don't even have to have a big bang on this: we could start with non-email pull requests to Linus and then extend outwards. James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:08 ` James Bottomley @ 2018-09-10 15:10 ` Linus Torvalds 2018-09-10 15:38 ` Sasha Levin 2018-09-10 15:13 ` Jiri Kosina 1 sibling, 1 reply; 162+ messages in thread From: Linus Torvalds @ 2018-09-10 15:10 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit On Mon, Sep 10, 2018 at 5:08 AM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: > > "Live without email - possible?" > > Can I propose one small alteration to the topic: > > "Patches without Email - Possible?" Yes, better. That's what I meant anyway. I still want the pull requests as email, and I still think email is often the best way to discuss things. It was more the "patch-bomb" model that I think it really wearing people down. I know it used to wear me down. I'm *so* much happier doing pull requests than handling patches. Linus ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:10 ` Linus Torvalds @ 2018-09-10 15:38 ` Sasha Levin 2018-09-10 15:47 ` James Bottomley ` (3 more replies) 0 siblings, 4 replies; 162+ messages in thread From: Sasha Levin @ 2018-09-10 15:38 UTC (permalink / raw) To: Linus Torvalds; +Cc: James Bottomley, ksummit On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: >On Mon, Sep 10, 2018 at 5:08 AM James Bottomley ><James.Bottomley@hansenpartnership.com> wrote: >> >> On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: >> > "Live without email - possible?" >> >> Can I propose one small alteration to the topic: >> >> "Patches without Email - Possible?" > >Yes, better. That's what I meant anyway. > >I still want the pull requests as email, and I still think email is >often the best way to discuss things. Yes, email is great for discussions, but one concern I have is that once discussions ended and a patch was merged, a lot of those discussions are lost forever. It's somewhat easy to google a patch and look in lkml archives to see some discussion as a result of the patch, but that's far from perfect: 1. For different patch revisions, some discussions manage to hide in the archives. 2. Discussions that resulted in a patch being sent aren't linked to the patch itself. 3. Any discussions after the patch was merged aren't easy to locate, specially if they're not in the same thread as the original patch. This makes the lives of stable/distro folks more difficult than it should be. Yes, some maintainers started adding links to lkml archives, but those are very inconsistent and often just point to the patch submission rather than relevant discussions. I'm not sure what's a good way to solve this, but I'd really like to stop losing this valuable information as a result of the current process. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:38 ` Sasha Levin @ 2018-09-10 15:47 ` James Bottomley 2018-09-10 15:55 ` Sasha Levin 2018-09-10 15:47 ` Konstantin Ryabitsev ` (2 subsequent siblings) 3 siblings, 1 reply; 162+ messages in thread From: James Bottomley @ 2018-09-10 15:47 UTC (permalink / raw) To: Sasha Levin, Linus Torvalds; +Cc: ksummit On Mon, 2018-09-10 at 15:38 +0000, Sasha Levin via Ksummit-discuss wrote: > On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: > > On Mon, Sep 10, 2018 at 5:08 AM James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: > > > > > > On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: > > > > "Live without email - possible?" > > > > > > Can I propose one small alteration to the topic: > > > > > > "Patches without Email - Possible?" > > > > Yes, better. That's what I meant anyway. > > > > I still want the pull requests as email, and I still think email is > > often the best way to discuss things. > > Yes, email is great for discussions, but one concern I have is that > once discussions ended and a patch was merged, a lot of those > discussions are lost forever. > > It's somewhat easy to google a patch and look in lkml archives to see > some discussion as a result of the patch, but that's far from > perfect: > > 1. For different patch revisions, some discussions manage to hide in > the archives. > 2. Discussions that resulted in a patch being sent aren't linked to > the patch itself. > 3. Any discussions after the patch was merged aren't easy to locate, > specially if they're not in the same thread as the original patch. > > This makes the lives of stable/distro folks more difficult than it > should be. I disagree on this. I have had occasion, when identifying patches that screwed something up, to go back to the emails to try to find out who did this and why. As long as you're used to search interfaces it's usually easy to find. Usually they are all threaded under the patch but the worst case I've seen is when v1, v2 ... vn aren't linked by thread, but even there searching for the specific patch set (0/n) subject title works. So I think the data is all there in multiple archives and we do have powerful enough tools to find it. James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:47 ` James Bottomley @ 2018-09-10 15:55 ` Sasha Levin 2018-09-10 16:13 ` James Bottomley 0 siblings, 1 reply; 162+ messages in thread From: Sasha Levin @ 2018-09-10 15:55 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit On Mon, Sep 10, 2018 at 08:47:07AM -0700, James Bottomley wrote: >On Mon, 2018-09-10 at 15:38 +0000, Sasha Levin via Ksummit-discuss >wrote: >> On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: >> > On Mon, Sep 10, 2018 at 5:08 AM James Bottomley >> > <James.Bottomley@hansenpartnership.com> wrote: >> > > >> > > On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: >> > > > "Live without email - possible?" >> > > >> > > Can I propose one small alteration to the topic: >> > > >> > > "Patches without Email - Possible?" >> > >> > Yes, better. That's what I meant anyway. >> > >> > I still want the pull requests as email, and I still think email is >> > often the best way to discuss things. >> >> Yes, email is great for discussions, but one concern I have is that >> once discussions ended and a patch was merged, a lot of those >> discussions are lost forever. >> >> It's somewhat easy to google a patch and look in lkml archives to see >> some discussion as a result of the patch, but that's far from >> perfect: >> >> 1. For different patch revisions, some discussions manage to hide in >> the archives. >> 2. Discussions that resulted in a patch being sent aren't linked to >> the patch itself. >> 3. Any discussions after the patch was merged aren't easy to locate, >> specially if they're not in the same thread as the original patch. >> >> This makes the lives of stable/distro folks more difficult than it >> should be. > >I disagree on this. I have had occasion, when identifying patches that >screwed something up, to go back to the emails to try to find out who >did this and why. As long as you're used to search interfaces it's >usually easy to find. Usually they are all threaded under the patch >but the worst case I've seen is when v1, v2 ... vn aren't linked by >thread, but even there searching for the specific patch set (0/n) >subject title works. So I think the data is all there in multiple >archives and we do have powerful enough tools to find it. Indeed, if *all* discussions happened in a single thread that was used to submit the patch then sure - it's straightforward. However, consider 2 scenarios that we encounter on a weekly basis: 1. We see a stable patch but not sure why/how it fixes an issue. The patch itself doesn't have enough information and there was no discussion after the patch was submitted. However, there was a lot of discussion in a completely unrelated thread unlinked from the patch submission. We can't find that because it doesn't refer to the patch at all, it just describes the problem and a solution. 2. We pull in a patch into the stable tree, but a few days later someone reports a bug and points to that patch. It's easier to solve these cases by grepping through mailboxes before shipping out stable releases, but it adds a considerable amount of effort. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:55 ` Sasha Levin @ 2018-09-10 16:13 ` James Bottomley 2018-09-10 16:24 ` Sasha Levin 0 siblings, 1 reply; 162+ messages in thread From: James Bottomley @ 2018-09-10 16:13 UTC (permalink / raw) To: Sasha Levin; +Cc: ksummit On Mon, 2018-09-10 at 15:55 +0000, Sasha Levin via Ksummit-discuss wrote: > On Mon, Sep 10, 2018 at 08:47:07AM -0700, James Bottomley wrote: > > On Mon, 2018-09-10 at 15:38 +0000, Sasha Levin via Ksummit-discuss > > wrote: > > > On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: > > > > On Mon, Sep 10, 2018 at 5:08 AM James Bottomley > > > > <James.Bottomley@hansenpartnership.com> wrote: > > > > > > > > > > On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: > > > > > > "Live without email - possible?" > > > > > > > > > > Can I propose one small alteration to the topic: > > > > > > > > > > "Patches without Email - Possible?" > > > > > > > > Yes, better. That's what I meant anyway. > > > > > > > > I still want the pull requests as email, and I still think > > > > email is often the best way to discuss things. > > > > > > Yes, email is great for discussions, but one concern I have is > > > that once discussions ended and a patch was merged, a lot of > > > those discussions are lost forever. > > > > > > It's somewhat easy to google a patch and look in lkml archives to > > > see some discussion as a result of the patch, but that's far from > > > perfect: > > > > > > 1. For different patch revisions, some discussions manage to hide > > > in the archives. > > > 2. Discussions that resulted in a patch being sent aren't linked > > > to the patch itself. > > > 3. Any discussions after the patch was merged aren't easy to > > > locate, specially if they're not in the same thread as the > > > original patch. > > > > > > This makes the lives of stable/distro folks more difficult than > > > it should be. > > > > I disagree on this. I have had occasion, when identifying patches > > that screwed something up, to go back to the emails to try to find > > out who did this and why. As long as you're used to search > > interfaces it's usually easy to find. Usually they are all > > threaded under the patch but the worst case I've seen is when v1, > > v2 ... vn aren't linked by thread, but even there searching for the > > specific patch set (0/n) subject title works. So I think the data > > is all there in multiple archives and we do have powerful enough > > tools to find it. > > Indeed, if *all* discussions happened in a single thread that was > used to submit the patch then sure - it's straightforward. However, > consider 2 scenarios that we encounter on a weekly basis: > > 1. We see a stable patch but not sure why/how it fixes an issue. The > patch itself doesn't have enough information and there was no > discussion after the patch was submitted. However, there was a lot of > discussion in a completely unrelated thread unlinked from the patch > submission. We can't find that because it doesn't refer to the patch > at all, it just describes the problem and a solution. This means the commit message was bad if it doesn't give you the information. If a patch is tagged for stable you know the Maintainer made the decision before it was committed and they should have the courtesy to explain the user visible issues (or make sure the submitter did). I really don't think you need to second guess the maintainer on this. There is a workflow issue in that not all maintainers tag for stable, but I think that could be a separate topic. > 2. We pull in a patch into the stable tree, but a few days later > someone reports a bug and points to that patch. It's easier to solve > these cases by grepping through mailboxes before shipping out stable > releases, but it adds a considerable amount of effort. So, again, don't second guess; triage by user visible fixes. If the patch doesn't really fix anything essential: revert it and notify the subsystem and if it does ask the relevant subsystem for help ... that is what they're there for. Sure, it's nice to have the historical information, but it shouldn't be your first port of call when you have a live subsystem and maintainer who should be on top of all the issues and should be more expert than you. James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:13 ` James Bottomley @ 2018-09-10 16:24 ` Sasha Levin 2018-09-10 17:10 ` James Bottomley 0 siblings, 1 reply; 162+ messages in thread From: Sasha Levin @ 2018-09-10 16:24 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit On Mon, Sep 10, 2018 at 09:13:39AM -0700, James Bottomley wrote: >On Mon, 2018-09-10 at 15:55 +0000, Sasha Levin via Ksummit-discuss >wrote: >> On Mon, Sep 10, 2018 at 08:47:07AM -0700, James Bottomley wrote: >> > On Mon, 2018-09-10 at 15:38 +0000, Sasha Levin via Ksummit-discuss >> > wrote: >> > > On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: >> > > > On Mon, Sep 10, 2018 at 5:08 AM James Bottomley >> > > > <James.Bottomley@hansenpartnership.com> wrote: >> > > > > >> > > > > On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: >> > > > > > "Live without email - possible?" >> > > > > >> > > > > Can I propose one small alteration to the topic: >> > > > > >> > > > > "Patches without Email - Possible?" >> > > > >> > > > Yes, better. That's what I meant anyway. >> > > > >> > > > I still want the pull requests as email, and I still think >> > > > email is often the best way to discuss things. >> > > >> > > Yes, email is great for discussions, but one concern I have is >> > > that once discussions ended and a patch was merged, a lot of >> > > those discussions are lost forever. >> > > >> > > It's somewhat easy to google a patch and look in lkml archives to >> > > see some discussion as a result of the patch, but that's far from >> > > perfect: >> > > >> > > 1. For different patch revisions, some discussions manage to hide >> > > in the archives. >> > > 2. Discussions that resulted in a patch being sent aren't linked >> > > to the patch itself. >> > > 3. Any discussions after the patch was merged aren't easy to >> > > locate, specially if they're not in the same thread as the >> > > original patch. >> > > >> > > This makes the lives of stable/distro folks more difficult than >> > > it should be. >> > >> > I disagree on this. I have had occasion, when identifying patches >> > that screwed something up, to go back to the emails to try to find >> > out who did this and why. As long as you're used to search >> > interfaces it's usually easy to find. Usually they are all >> > threaded under the patch but the worst case I've seen is when v1, >> > v2 ... vn aren't linked by thread, but even there searching for the >> > specific patch set (0/n) subject title works. So I think the data >> > is all there in multiple archives and we do have powerful enough >> > tools to find it. >> >> Indeed, if *all* discussions happened in a single thread that was >> used to submit the patch then sure - it's straightforward. However, >> consider 2 scenarios that we encounter on a weekly basis: >> >> 1. We see a stable patch but not sure why/how it fixes an issue. The >> patch itself doesn't have enough information and there was no >> discussion after the patch was submitted. However, there was a lot of >> discussion in a completely unrelated thread unlinked from the patch >> submission. We can't find that because it doesn't refer to the patch >> at all, it just describes the problem and a solution. > >This means the commit message was bad if it doesn't give you the >information. If a patch is tagged for stable you know the Maintainer >made the decision before it was committed and they should have the >courtesy to explain the user visible issues (or make sure the submitter >did). I really don't think you need to second guess the maintainer on >this. We don't always do it to "second guess". A more common case is us trying to understand if we missed anything. Look at the following patch (from last week) for example: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d806afa495e2e2a1a726e26c5e44f27818e804c1 It states no functional changes, there are no related patches before/after it, and yet it's still tagged for stable. Is it us missing a related fix? Is it just not stable material? How do we explain it to ourselves? Another related reason is that I look at patches without stable tags trying to understand whether they should go in stable or not, and then I try to understand whether a certain patch is a fix or not. >There is a workflow issue in that not all maintainers tag for stable, >but I think that could be a separate topic. > >> 2. We pull in a patch into the stable tree, but a few days later >> someone reports a bug and points to that patch. It's easier to solve >> these cases by grepping through mailboxes before shipping out stable >> releases, but it adds a considerable amount of effort. > >So, again, don't second guess; triage by user visible fixes. If the >patch doesn't really fix anything essential: revert it and notify the >subsystem and if it does ask the relevant subsystem for help ... that >is what they're there for. > >Sure, it's nice to have the historical information, but it shouldn't be >your first port of call when you have a live subsystem and maintainer >who should be on top of all the issues and should be more expert than >you. This is a bit different, in these cases I want to understand if I should be applying an additional fix or reverting a patch from stable. The sooner we get that information the less known buggy kernels will be shipped out. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:24 ` Sasha Levin @ 2018-09-10 17:10 ` James Bottomley 0 siblings, 0 replies; 162+ messages in thread From: James Bottomley @ 2018-09-10 17:10 UTC (permalink / raw) To: Sasha Levin; +Cc: ksummit On Mon, 2018-09-10 at 16:24 +0000, Sasha Levin via Ksummit-discuss wrote: > On Mon, Sep 10, 2018 at 09:13:39AM -0700, James Bottomley wrote: > > On Mon, 2018-09-10 at 15:55 +0000, Sasha Levin via Ksummit-discuss [...] > > > Indeed, if *all* discussions happened in a single thread that was > > > used to submit the patch then sure - it's straightforward. > > > However, consider 2 scenarios that we encounter on a weekly > > > basis: > > > > > > 1. We see a stable patch but not sure why/how it fixes an issue. > > > The patch itself doesn't have enough information and there was no > > > discussion after the patch was submitted. However, there was a > > > lot of discussion in a completely unrelated thread unlinked from > > > the patch submission. We can't find that because it doesn't refer > > > to the patch at all, it just describes the problem and a > > > solution. > > > > This means the commit message was bad if it doesn't give you the > > information. If a patch is tagged for stable you know the > > Maintainer made the decision before it was committed and they > > should have the courtesy to explain the user visible issues (or > > make sure the submitter did). I really don't think you need to > > second guess the maintainer on this. > > We don't always do it to "second guess". A more common case is us > trying to understand if we missed anything. Look at the following > patch (from last week) for example: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux. > git/commit/?id=d806afa495e2e2a1a726e26c5e44f27818e804c1 > > It states no functional changes, there are no related patches > before/after it, and yet it's still tagged for stable. Is it us > missing a related fix? Is it just not stable material? How do we > explain it to ourselves? It's a whitespace change ... I thought stable policy was to reject those without further consideration. However, given the #L1TF qualifier, I think it's a precursor patch for another L1TF change, isn't it? What's wrong with if in doubt, ask the maintainer. > Another related reason is that I look at patches without stable tags > trying to understand whether they should go in stable or not, and > then I try to understand whether a certain patch is a fix or not. Why? If a Maintainer didn't tag it and no-one else submitted it, why go looking for trouble? I really strongly think stable should be a push process not a random pull one. > > There is a workflow issue in that not all maintainers tag for > > stable, but I think that could be a separate topic. > > > > > 2. We pull in a patch into the stable tree, but a few days later > > > someone reports a bug and points to that patch. It's easier to > > > solve these cases by grepping through mailboxes before shipping > > > out stable releases, but it adds a considerable amount of effort. > > > > So, again, don't second guess; triage by user visible fixes. If > > the patch doesn't really fix anything essential: revert it and > > notify the subsystem and if it does ask the relevant subsystem for > > help ... that is what they're there for. > > > > Sure, it's nice to have the historical information, but it > > shouldn't be your first port of call when you have a live subsystem > > and maintainer who should be on top of all the issues and should be > > more expert than you. > > This is a bit different, in these cases I want to understand if I > should be applying an additional fix or reverting a patch from > stable. The sooner we get that information the less known buggy > kernels will be shipped out. So simply asking will get you that information. James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:38 ` Sasha Levin 2018-09-10 15:47 ` James Bottomley @ 2018-09-10 15:47 ` Konstantin Ryabitsev 2018-09-10 15:56 ` Sasha Levin 2018-09-10 16:07 ` Daniel Vetter 2018-09-10 15:49 ` Mark Brown 2018-09-10 16:33 ` Olof Johansson 3 siblings, 2 replies; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-10 15:47 UTC (permalink / raw) To: Sasha Levin; +Cc: James Bottomley, ksummit On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss wrote: >Yes, some maintainers started adding links to lkml archives, but those >are very inconsistent and often just point to the patch submission >rather than relevant discussions. > >I'm not sure what's a good way to solve this, but I'd really like to >stop losing this valuable information as a result of the current >process. This is partly the goal behind cregit: https://cregit.linuxsources.org/ The plan is that the next version of cregit will become an official kernel.org resource some time mid-next year, and will aggregate as much information about the kernel code as it can from various places, including patchwork. -K ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:47 ` Konstantin Ryabitsev @ 2018-09-10 15:56 ` Sasha Levin 2018-09-10 16:02 ` Konstantin Ryabitsev 2018-09-10 16:07 ` Daniel Vetter 1 sibling, 1 reply; 162+ messages in thread From: Sasha Levin @ 2018-09-10 15:56 UTC (permalink / raw) To: Linus Torvalds, James Bottomley, ksummit On Mon, Sep 10, 2018 at 11:47:38AM -0400, Konstantin Ryabitsev wrote: >On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss wrote: >>Yes, some maintainers started adding links to lkml archives, but those >>are very inconsistent and often just point to the patch submission >>rather than relevant discussions. >> >>I'm not sure what's a good way to solve this, but I'd really like to >>stop losing this valuable information as a result of the current >>process. > >This is partly the goal behind cregit: > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcregit.linuxsources.org%2F&data=02%7C01%7CAlexander.Levin%40microsoft.com%7Cabcc8f65199b4c5e4dc108d61734a674%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636721912238696228&sdata=ocQoQHzDCZuFwYxTIzDrg%2BNHKUHmZbLQElEcHK7Aaeo%3D&reserved=0 > >The plan is that the next version of cregit will become an official >kernel.org resource some time mid-next year, and will aggregate as >much information about the kernel code as it can from various places, >including patchwork. I thought cregit was more about identifying who wrote what line of code rather than all the metadata around that line of code? -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:56 ` Sasha Levin @ 2018-09-10 16:02 ` Konstantin Ryabitsev 0 siblings, 0 replies; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-10 16:02 UTC (permalink / raw) To: Sasha Levin; +Cc: James Bottomley, ksummit [-- Attachment #1: Type: text/plain, Size: 730 bytes --] On Mon, Sep 10, 2018 at 03:56:27PM +0000, Sasha Levin via Ksummit-discuss wrote: >>The plan is that the next version of cregit will become an official >>kernel.org resource some time mid-next year, and will aggregate as >>much information about the kernel code as it can from various places, >>including patchwork. > >I thought cregit was more about identifying who wrote what line of code >rather than all the metadata around that line of code? Yes, that's the primary goal, but the secondary goal is to provide as much information about the lifecycle of each change as possible. The way code metamorphoses from the initial submission to the final accepted commit is an important part of cregit's mission. -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:47 ` Konstantin Ryabitsev 2018-09-10 15:56 ` Sasha Levin @ 2018-09-10 16:07 ` Daniel Vetter 2018-09-10 16:18 ` Konstantin Ryabitsev 2018-09-10 19:48 ` Laurent Pinchart 1 sibling, 2 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 16:07 UTC (permalink / raw) To: Sasha Levin, Linus Torvalds, James Bottomley, ksummit On Mon, Sep 10, 2018 at 5:47 PM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: > On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss > wrote: >> >> Yes, some maintainers started adding links to lkml archives, but those >> are very inconsistent and often just point to the patch submission >> rather than relevant discussions. >> >> I'm not sure what's a good way to solve this, but I'd really like to >> stop losing this valuable information as a result of the current >> process. > > > This is partly the goal behind cregit: > > https://cregit.linuxsources.org/ > > The plan is that the next version of cregit will become an official > kernel.org resource some time mid-next year, and will aggregate as much > information about the kernel code as it can from various places, including > patchwork. Assuming we do indeed switch some parts of the drm process over to gitlab (very big assumption here), whom would we need to chat with to do that? Atm what we're doing with patchwork is automatically add a Link: with the https:// patchwork url for that patch. Which then has links to the overall series, with CI results and discussions and all that. Plan for gitlab is to do something similar, if we start using it for real for anything. Would that be good enough? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:07 ` Daniel Vetter @ 2018-09-10 16:18 ` Konstantin Ryabitsev 2018-09-10 16:23 ` Daniel Vetter 2018-09-10 19:48 ` Laurent Pinchart 1 sibling, 1 reply; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-10 16:18 UTC (permalink / raw) To: Daniel Vetter; +Cc: James Bottomley, ksummit [-- Attachment #1: Type: text/plain, Size: 1215 bytes --] On Mon, Sep 10, 2018 at 06:07:35PM +0200, Daniel Vetter wrote: >Assuming we do indeed switch some parts of the drm process over to >gitlab (very big assumption here), whom would we need to chat with to >do that? Hm... For the purposes of cregit or repository hosting? >Atm what we're doing with patchwork is automatically add a Link: with >the https:// patchwork url for that patch. Which then has links to the >overall series, with CI results and discussions and all that. Plan for >gitlab is to do something similar, if we start using it for real for >anything. Would that be good enough? That shouldn't be necessary in the near future. There is work under way for patchwork to accept message-id based URLs, so using the lkml.kernel.org/r/message-id URLs in commit messages should be enough for cregit to provide a link to the relevant patchwork thread. We will also probably end up integrating lore.kernel.org/patchwork with git in a way that would associate patches with final commit-ids and auto-archive them. It's not going to be 100% accurate for various reasons, but will at lest provide more hooks for projects like cregit to provide extra details about git commits. -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:18 ` Konstantin Ryabitsev @ 2018-09-10 16:23 ` Daniel Vetter 2018-09-10 16:41 ` Konstantin Ryabitsev 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 16:23 UTC (permalink / raw) To: Daniel Vetter, Sasha Levin, Linus Torvalds, James Bottomley, ksummit On Mon, Sep 10, 2018 at 6:18 PM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: > On Mon, Sep 10, 2018 at 06:07:35PM +0200, Daniel Vetter wrote: >> >> Assuming we do indeed switch some parts of the drm process over to >> gitlab (very big assumption here), whom would we need to chat with to >> do that? > > > Hm... For the purposes of cregit or repository hosting? For cregit integration. Tbh I don't even know how the current mailing lists hosted on freedesktop.org infrastructure are integrated into cregit. But I assume they are somehow, since that's were all the drm talk is happening. gitlab will also be hosted on fd.o infrastructure for us. >> Atm what we're doing with patchwork is automatically add a Link: with >> the https:// patchwork url for that patch. Which then has links to the >> overall series, with CI results and discussions and all that. Plan for >> gitlab is to do something similar, if we start using it for real for >> anything. Would that be good enough? > > > That shouldn't be necessary in the near future. There is work under way for > patchwork to accept message-id based URLs, so using the > lkml.kernel.org/r/message-id URLs in commit messages should be enough for > cregit to provide a link to the relevant patchwork thread. We will also > probably end up integrating lore.kernel.org/patchwork with git in a way that > would associate patches with final commit-ids and auto-archive them. It's > not going to be 100% accurate for various reasons, but will at lest provide > more hooks for projects like cregit to provide extra details about git > commits. There's at least 4 forks of patchwork :-/ The one we have on fd.o has been doing this since ages. We added the Link: stuff so you can easily go from e.g. git log to the patch discussion, without a detour through google. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:23 ` Daniel Vetter @ 2018-09-10 16:41 ` Konstantin Ryabitsev 2018-09-10 17:06 ` Daniel Vetter 0 siblings, 1 reply; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-10 16:41 UTC (permalink / raw) To: Daniel Vetter; +Cc: James Bottomley, ksummit [-- Attachment #1: Type: text/plain, Size: 1816 bytes --] On Mon, Sep 10, 2018 at 06:23:52PM +0200, Daniel Vetter wrote: >> Hm... For the purposes of cregit or repository hosting? > >For cregit integration. Tbh I don't even know how the current mailing >lists hosted on freedesktop.org infrastructure are integrated into >cregit. But I assume they are somehow, since that's were all the drm >talk is happening. gitlab will also be hosted on fd.o infrastructure >for us. Cregit only considers LKML and the mainline tree -- at least right now. So, as long as all patches and discussions are cc'd to LKML, they will be within cregit's reach. I'm not sure there are any plans to look at any other lists at this point (I'm only very tangentially involved in cregit's development). Kate Stewart would be the right person to ask this. >> That shouldn't be necessary in the near future. There is work under >> way for >> patchwork to accept message-id based URLs, so using the >> lkml.kernel.org/r/message-id URLs in commit messages should be enough for >> cregit to provide a link to the relevant patchwork thread. We will also >> probably end up integrating lore.kernel.org/patchwork with git in a way that >> would associate patches with final commit-ids and auto-archive them. It's >> not going to be 100% accurate for various reasons, but will at lest provide >> more hooks for projects like cregit to provide extra details about git >> commits. > >There's at least 4 forks of patchwork :-/ The one we have on fd.o has >been doing this since ages. We added the Link: stuff so you can easily >go from e.g. git log to the patch discussion, without a detour through >google. It's too bad that this hasn't percolated up to ozlabs, because I believe numeric-ID based patch links are actually harmful because they are 100% lossy. -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:41 ` Konstantin Ryabitsev @ 2018-09-10 17:06 ` Daniel Vetter 0 siblings, 0 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 17:06 UTC (permalink / raw) To: Daniel Vetter, Sasha Levin, Linus Torvalds, James Bottomley, ksummit On Mon, Sep 10, 2018 at 6:41 PM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: > On Mon, Sep 10, 2018 at 06:23:52PM +0200, Daniel Vetter wrote: >>> >>> Hm... For the purposes of cregit or repository hosting? >> >> >> For cregit integration. Tbh I don't even know how the current mailing >> lists hosted on freedesktop.org infrastructure are integrated into >> cregit. But I assume they are somehow, since that's were all the drm >> talk is happening. gitlab will also be hosted on fd.o infrastructure >> for us. > > > Cregit only considers LKML and the mainline tree -- at least right now. So, > as long as all patches and discussions are cc'd to LKML, they will be within > cregit's reach. I'm not sure there are any plans to look at any other lists > at this point (I'm only very tangentially involved in cregit's development). > Kate Stewart would be the right person to ask this. Hm yeah that's a bit a bummer. We don't tend to cc: lkml on anything we do. And I think that holds true for many subsystems (but honestly I didn't check). Can you pls pull Kate into this thread, so I have their contact information? >>> That shouldn't be necessary in the near future. There is work under way >>> for >>> patchwork to accept message-id based URLs, so using the >>> lkml.kernel.org/r/message-id URLs in commit messages should be enough for >>> cregit to provide a link to the relevant patchwork thread. We will also >>> probably end up integrating lore.kernel.org/patchwork with git in a way >>> that >>> would associate patches with final commit-ids and auto-archive them. It's >>> not going to be 100% accurate for various reasons, but will at lest >>> provide >>> more hooks for projects like cregit to provide extra details about git >>> commits. >> >> >> There's at least 4 forks of patchwork :-/ The one we have on fd.o has >> been doing this since ages. We added the Link: stuff so you can easily >> go from e.g. git log to the patch discussion, without a detour through >> google. > > > It's too bad that this hasn't percolated up to ozlabs, because I believe > numeric-ID based patch links are actually harmful because they are 100% > lossy. We tried to upstream - it died in a bikeshed of competing approaches and someone else won (but then took years longer to get their approach merged). Anyway, from our experiences patchwork, even with the things you've listed implemented, is miles away from what we actually need. It's definitely better than old patchwork though. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:07 ` Daniel Vetter 2018-09-10 16:18 ` Konstantin Ryabitsev @ 2018-09-10 19:48 ` Laurent Pinchart 2018-09-10 20:50 ` Daniel Vetter 1 sibling, 1 reply; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 19:48 UTC (permalink / raw) To: ksummit-discuss; +Cc: James Bottomley Hi Daniel, On Monday, 10 September 2018 19:07:35 EEST Daniel Vetter wrote: > On Mon, Sep 10, 2018 at 5:47 PM, Konstantin Ryabitsev wrote: > > On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin wrote: > >> Yes, some maintainers started adding links to lkml archives, but those > >> are very inconsistent and often just point to the patch submission > >> rather than relevant discussions. > >> > >> I'm not sure what's a good way to solve this, but I'd really like to > >> stop losing this valuable information as a result of the current > >> process. > > > > This is partly the goal behind cregit: > > > > https://cregit.linuxsources.org/ > > > > The plan is that the next version of cregit will become an official > > kernel.org resource some time mid-next year, and will aggregate as much > > information about the kernel code as it can from various places, including > > patchwork. > > Assuming we do indeed switch some parts of the drm process over to > gitlab (very big assumption here), whom would we need to chat with to > do that? Could you elaborate on what that means exactly ? For most subsystems the development process encompasses a large number of tasks, so switching to gitlab doesn't mean much without knowing exactly how the new process would look like. Which part(s) of the development process would be affected, and how ? And as an added bonus, it would be helpful if you could also describe why you think they don't work today and would be better handled differently. > Atm what we're doing with patchwork is automatically add a Link: with > the https:// patchwork url for that patch. Which then has links to the > overall series, with CI results and discussions and all that. Plan for > gitlab is to do something similar, if we start using it for real for > anything. Would that be good enough? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 19:48 ` Laurent Pinchart @ 2018-09-10 20:50 ` Daniel Vetter 0 siblings, 0 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 20:50 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James Bottomley, ksummit On Mon, Sep 10, 2018 at 9:48 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Daniel, > > On Monday, 10 September 2018 19:07:35 EEST Daniel Vetter wrote: >> On Mon, Sep 10, 2018 at 5:47 PM, Konstantin Ryabitsev wrote: >> > On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin wrote: >> >> Yes, some maintainers started adding links to lkml archives, but those >> >> are very inconsistent and often just point to the patch submission >> >> rather than relevant discussions. >> >> >> >> I'm not sure what's a good way to solve this, but I'd really like to >> >> stop losing this valuable information as a result of the current >> >> process. >> > >> > This is partly the goal behind cregit: >> > >> > https://cregit.linuxsources.org/ >> > >> > The plan is that the next version of cregit will become an official >> > kernel.org resource some time mid-next year, and will aggregate as much >> > information about the kernel code as it can from various places, including >> > patchwork. >> >> Assuming we do indeed switch some parts of the drm process over to >> gitlab (very big assumption here), whom would we need to chat with to >> do that? > > Could you elaborate on what that means exactly ? For most subsystems the > development process encompasses a large number of tasks, so switching to > gitlab doesn't mean much without knowing exactly how the new process would > look like. Which part(s) of the development process would be affected, and how > ? And as an added bonus, it would be helpful if you could also describe why > you think they don't work today and would be better handled differently. Let's move all the "how to gitab, or can we live without email?" discussions in the other part of this thread. This here was just a quick question about cregit (and I already regret that I mentioned gitlab here, it seems to somewhat distract). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:38 ` Sasha Levin 2018-09-10 15:47 ` James Bottomley 2018-09-10 15:47 ` Konstantin Ryabitsev @ 2018-09-10 15:49 ` Mark Brown 2018-09-10 16:33 ` Olof Johansson 3 siblings, 0 replies; 162+ messages in thread From: Mark Brown @ 2018-09-10 15:49 UTC (permalink / raw) To: Sasha Levin; +Cc: James Bottomley, ksummit [-- Attachment #1: Type: text/plain, Size: 667 bytes --] On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss wrote: > Yes, some maintainers started adding links to lkml archives, but those > are very inconsistent and often just point to the patch submission > rather than relevant discussions. > I'm not sure what's a good way to solve this, but I'd really like to > stop losing this valuable information as a result of the current > process. Patchwork does a credible job of that for me - I especially like the fact that you can look things up by hash from a commit in your local tree. It's not ideally formatted but it mostly gets the job done as well as anything else I've seen for archive use. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:38 ` Sasha Levin ` (2 preceding siblings ...) 2018-09-10 15:49 ` Mark Brown @ 2018-09-10 16:33 ` Olof Johansson 2018-09-10 19:59 ` Laurent Pinchart 3 siblings, 1 reply; 162+ messages in thread From: Olof Johansson @ 2018-09-10 16:33 UTC (permalink / raw) To: Sasha Levin; +Cc: James Bottomley, ksummit Hi, On Mon, Sep 10, 2018 at 8:38 AM, Sasha Levin via Ksummit-discuss <ksummit-discuss@lists.linuxfoundation.org> wrote: > On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: >>On Mon, Sep 10, 2018 at 5:08 AM James Bottomley >><James.Bottomley@hansenpartnership.com> wrote: >>> >>> On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: >>> > "Live without email - possible?" >>> >>> Can I propose one small alteration to the topic: >>> >>> "Patches without Email - Possible?" >> >>Yes, better. That's what I meant anyway. >> >>I still want the pull requests as email, and I still think email is >>often the best way to discuss things. > > Yes, email is great for discussions, but one concern I have is that once > discussions ended and a patch was merged, a lot of those discussions are > lost forever. It's great for ephemeral discussions of the current patch set, but several of your points sort of indicate that it _isn't_ a good discussion forum either. > > It's somewhat easy to google a patch and look in lkml archives to see > some discussion as a result of the patch, but that's far from perfect: > > 1. For different patch revisions, some discussions manage to hide in > the archives. > 2. Discussions that resulted in a patch being sent aren't linked to the > patch itself. > 3. Any discussions after the patch was merged aren't easy to locate, > specially if they're not in the same thread as the original patch. > > This makes the lives of stable/distro folks more difficult than it > should be. > > Yes, some maintainers started adding links to lkml archives, but those > are very inconsistent and often just point to the patch submission > rather than relevant discussions. It makes it a pain for me as well. The way we deal with code coming in is that very often we don't see patches until they're sent to us in a pull request. I look through them (i.e. a light review), and if I find something, I'll go look for the patch on the mailing list and reply on it. If that patch is up at higher versions, there's no way for me to easily find all previous discussion about it, which sometimes means I will have conflicting feedback from some other maintainer. If it's minor feedback that isn't a really big deal, it's better to see the other side early on and just not introduce the noise and conflicting requests to the contributor. Having worked in several corporate setups, none of them are ideal, but some of them do fill the gaps we have while they introduce others. There is definitely lots of opportunity for better tooling all around. > I'm not sure what's a good way to solve this, but I'd really like to > stop losing this valuable information as a result of the current > process. I think any tool we choose can/should/will have an email backed such that email archives could always be a canonical historical fallback. Especially for services where URLs to pull requests might not be around 5 years from now, etc. We've already gone through a cycle of this for email archives recently. -Olof ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:33 ` Olof Johansson @ 2018-09-10 19:59 ` Laurent Pinchart 2018-09-10 21:30 ` Josh Triplett 0 siblings, 1 reply; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 19:59 UTC (permalink / raw) To: ksummit-discuss; +Cc: James Bottomley Hi, On Monday, 10 September 2018 19:33:09 EEST Olof Johansson wrote: > On Mon, Sep 10, 2018 at 8:38 AM, Sasha Levin wrote: > > On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote: > >> On Mon, Sep 10, 2018 at 5:08 AM James Bottomley wrote: > >>> On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote: > >>>> "Live without email - possible?" > >>> > >>> Can I propose one small alteration to the topic: > >>> "Patches without Email - Possible?" > >> > >> Yes, better. That's what I meant anyway. > >> > >> I still want the pull requests as email, and I still think email is > >> often the best way to discuss things. > >> > > Yes, email is great for discussions, but one concern I have is that once > > discussions ended and a patch was merged, a lot of those discussions are > > lost forever. > > It's great for ephemeral discussions of the current patch set, but > several of your points sort of indicate that it _isn't_ a good > discussion forum either. > > > It's somewhat easy to google a patch and look in lkml archives to see > > some discussion as a result of the patch, but that's far from perfect: > > > > 1. For different patch revisions, some discussions manage to hide in > > the archives. > > 2. Discussions that resulted in a patch being sent aren't linked to the > > patch itself. > > 3. Any discussions after the patch was merged aren't easy to locate, > > specially if they're not in the same thread as the original patch. > > > > This makes the lives of stable/distro folks more difficult than it > > should be. > > > > Yes, some maintainers started adding links to lkml archives, but those > > are very inconsistent and often just point to the patch submission > > rather than relevant discussions. > > It makes it a pain for me as well. The way we deal with code coming in > is that very often we don't see patches until they're sent to us in a > pull request. I look through them (i.e. a light review), and if I find > something, I'll go look for the patch on the mailing list and reply on > it. > > If that patch is up at higher versions, there's no way for me to > easily find all previous discussion about it, which sometimes means I > will have conflicting feedback from some other maintainer. If it's > minor feedback that isn't a really big deal, it's better to see the > other side early on and just not introduce the noise and conflicting > requests to the contributor. > > Having worked in several corporate setups, none of them are ideal, but > some of them do fill the gaps we have while they introduce others. > There is definitely lots of opportunity for better tooling all around. One of the issues here is that patch series don't have fixed boundaries over their lifetime, the same way patches don't. A patch can evolve in scope from version to version, and similarly so can a patch series. It's not uncommon for patches to be dropped or added and for series to be split or merged. I've in the past incorporated part of an RFC patch series in the v1 of a series with a larger scope (after discussing it with the original developer of course). While in many cases we can version both patch and series, it's not uncommon for subjects to be changed and scopes to be extended or shrunk. I would distrust a system claiming it can automatically track all patch series over their lifetime, always keeping history linked together. That being said, if we could make that tracking information easily accessible in the common case where it actually exists, that would already be a good step forward in tooling improvement. > > I'm not sure what's a good way to solve this, but I'd really like to > > stop losing this valuable information as a result of the current > > process. > > I think any tool we choose can/should/will have an email backed such > that email archives could always be a canonical historical fallback. > Especially for services where URLs to pull requests might not be > around 5 years from now, etc. We've already gone through a cycle of > this for email archives recently. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 19:59 ` Laurent Pinchart @ 2018-09-10 21:30 ` Josh Triplett 2018-09-10 23:00 ` Laurent Pinchart 2018-09-10 23:16 ` Daniel Vetter 0 siblings, 2 replies; 162+ messages in thread From: Josh Triplett @ 2018-09-10 21:30 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James Bottomley, ksummit-discuss On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote: > One of the issues here is that patch series don't have fixed boundaries over > their lifetime, the same way patches don't. A patch can evolve in scope from > version to version, and similarly so can a patch series. It's not uncommon for > patches to be dropped or added and for series to be split or merged. I've in > the past incorporated part of an RFC patch series in the v1 of a series with a > larger scope (after discussing it with the original developer of course). I do have some tools and algorithms that could be adapted to help cross-match patch series and show how they evolve over time. It isn't that hard to detect patch reordering and show interdiffs between corresponding patches. Extending that to match patches between series isn't much harder. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:30 ` Josh Triplett @ 2018-09-10 23:00 ` Laurent Pinchart 2018-09-10 23:16 ` Daniel Vetter 1 sibling, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 23:00 UTC (permalink / raw) To: Josh Triplett; +Cc: James Bottomley, ksummit-discuss Hi Josh, On Tuesday, 11 September 2018 00:30:19 EEST Josh Triplett wrote: > On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote: > > One of the issues here is that patch series don't have fixed boundaries > > over their lifetime, the same way patches don't. A patch can evolve in > > scope from version to version, and similarly so can a patch series. It's > > not uncommon for patches to be dropped or added and for series to be > > split or merged. I've in the past incorporated part of an RFC patch > > series in the v1 of a series with a larger scope (after discussing it > > with the original developer of course). > > I do have some tools and algorithms that could be adapted to help > cross-match patch series and show how they evolve over time. It isn't > that hard to detect patch reordering and show interdiffs between > corresponding patches. Extending that to match patches between series > isn't much harder. That would be a very nice addition to patchwork. I believe we need heuristics to do this, and by definition they will never achieve a 100% success rate, but if we can find most links between patch series, we'll be in a much better position than we are now. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:30 ` Josh Triplett 2018-09-10 23:00 ` Laurent Pinchart @ 2018-09-10 23:16 ` Daniel Vetter 2018-09-11 1:14 ` Josh Triplett 1 sibling, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 23:16 UTC (permalink / raw) To: Josh Triplett; +Cc: James Bottomley, ksummit On Mon, Sep 10, 2018 at 11:30 PM, Josh Triplett <josh@joshtriplett.org> wrote: > On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote: >> One of the issues here is that patch series don't have fixed boundaries over >> their lifetime, the same way patches don't. A patch can evolve in scope from >> version to version, and similarly so can a patch series. It's not uncommon for >> patches to be dropped or added and for series to be split or merged. I've in >> the past incorporated part of an RFC patch series in the v1 of a series with a >> larger scope (after discussing it with the original developer of course). > > I do have some tools and algorithms that could be adapted to help > cross-match patch series and show how they evolve over time. It isn't > that hard to detect patch reordering and show interdiffs between > corresponding patches. Extending that to match patches between series > isn't much harder. Is that built on top of the new git range-diff tool, or at least that concept? Or something else? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 23:16 ` Daniel Vetter @ 2018-09-11 1:14 ` Josh Triplett 0 siblings, 0 replies; 162+ messages in thread From: Josh Triplett @ 2018-09-11 1:14 UTC (permalink / raw) To: Daniel Vetter; +Cc: James Bottomley, ksummit On Tue, Sep 11, 2018 at 01:16:18AM +0200, Daniel Vetter wrote: > On Mon, Sep 10, 2018 at 11:30 PM, Josh Triplett <josh@joshtriplett.org> wrote: > > On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote: > >> One of the issues here is that patch series don't have fixed boundaries over > >> their lifetime, the same way patches don't. A patch can evolve in scope from > >> version to version, and similarly so can a patch series. It's not uncommon for > >> patches to be dropped or added and for series to be split or merged. I've in > >> the past incorporated part of an RFC patch series in the v1 of a series with a > >> larger scope (after discussing it with the original developer of course). > > > > I do have some tools and algorithms that could be adapted to help > > cross-match patch series and show how they evolve over time. It isn't > > that hard to detect patch reordering and show interdiffs between > > corresponding patches. Extending that to match patches between series > > isn't much harder. > > Is that built on top of the new git range-diff tool, or at least that > concept? Or something else? Same concept, just a different implementation of an algorithm comparable to tbdiff's. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:08 ` James Bottomley 2018-09-10 15:10 ` Linus Torvalds @ 2018-09-10 15:13 ` Jiri Kosina 2018-09-10 15:20 ` James Bottomley ` (3 more replies) 1 sibling, 4 replies; 162+ messages in thread From: Jiri Kosina @ 2018-09-10 15:13 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit On Mon, 10 Sep 2018, James Bottomley wrote: > 1. How do reviews happen? Non email projects tend to have only one > review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do > we want to pick a technology or allow multiple? I don't think this > is kernel wide, it could be a sybsystem choice. Yeah, but OTOH even now I've heard a lot of feedback about the irregular contributors / newcomers being confused by different subsystems having different processess and requirements; and those are basically just rather "minor" things currently (bugzilla usage, patchwork usage, subscriber-only mailinglists, etc), but it's still enough to confuse the hell out of people. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:13 ` Jiri Kosina @ 2018-09-10 15:20 ` James Bottomley 2018-09-10 15:31 ` Sasha Levin ` (2 subsequent siblings) 3 siblings, 0 replies; 162+ messages in thread From: James Bottomley @ 2018-09-10 15:20 UTC (permalink / raw) To: Jiri Kosina; +Cc: ksummit On Mon, 2018-09-10 at 17:13 +0200, Jiri Kosina wrote: > On Mon, 10 Sep 2018, James Bottomley wrote: > > > 1. How do reviews happen? Non email projects tend to have only > > one review mechanism (gerrit, github, gitlab, etc.) and stick to > > it. Do we want to pick a technology or allow multiple? I don't > > think this is kernel wide, it could be a sybsystem choice. > > Yeah, but OTOH even now I've heard a lot of feedback about the > irregular contributors / newcomers being confused by different > subsystems having different processess and requirements; and those > are basically just rather "minor" things currently (bugzilla usage, > patchwork usage, subscriber-only mailinglists, etc), but it's still > enough to confuse the hell out of people. Well, I don't think it has to be a github/gitlab process. It's not impossible to craft a bugzilla based process for handling patches ... although I bet it would have to be a pretty dedicated bugzilla person to sign up to fix all the problem interactions and missing pieces. I also don't think the confusion will go away. Even most github projects have huge issues in this regard: fine, it's easy to submit a pull request, but not at all clear what you do when travis auto rejects the pull because you're not in the cabal or you didn't sign the correct CLA or it simply got it wrong and crashed before it got to the end of testing your code. James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:13 ` Jiri Kosina 2018-09-10 15:20 ` James Bottomley @ 2018-09-10 15:31 ` Sasha Levin 2018-09-10 20:15 ` Laurent Pinchart 2018-09-11 8:41 ` Jani Nikula 3 siblings, 0 replies; 162+ messages in thread From: Sasha Levin @ 2018-09-10 15:31 UTC (permalink / raw) To: Jiri Kosina; +Cc: James Bottomley, ksummit On Mon, Sep 10, 2018 at 05:13:05PM +0200, Jiri Kosina wrote: >On Mon, 10 Sep 2018, James Bottomley wrote: > >> 1. How do reviews happen? Non email projects tend to have only one >> review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do >> we want to pick a technology or allow multiple? I don't think this >> is kernel wide, it could be a sybsystem choice. > >Yeah, but OTOH even now I've heard a lot of feedback about the irregular >contributors / newcomers being confused by different subsystems having >different processess and requirements; and those are basically just rather >"minor" things currently (bugzilla usage, patchwork usage, subscriber-only >mailinglists, etc), but it's still enough to confuse the hell out of >people. Similarily with stable tags: some subsystems do not allow authors to tag patches for stable, which in turn means people don't add these tags in any of their patches, even to other subsystems, to "play safe". -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:13 ` Jiri Kosina 2018-09-10 15:20 ` James Bottomley 2018-09-10 15:31 ` Sasha Levin @ 2018-09-10 20:15 ` Laurent Pinchart 2018-09-10 21:09 ` Sean Paul 2018-09-11 8:44 ` Jani Nikula 2018-09-11 8:41 ` Jani Nikula 3 siblings, 2 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 20:15 UTC (permalink / raw) To: ksummit-discuss; +Cc: James Bottomley On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote: > On Mon, 10 Sep 2018, James Bottomley wrote: > > 1. How do reviews happen? Non email projects tend to have only one > > review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do > > we want to pick a technology or allow multiple? I don't think this > > is kernel wide, it could be a sybsystem choice. > > Yeah, but OTOH even now I've heard a lot of feedback about the irregular > contributors / newcomers being confused by different subsystems having > different processess and requirements; and those are basically just rather > "minor" things currently (bugzilla usage, patchwork usage, subscriber-only > mailinglists, etc), but it's still enough to confuse the hell out of > people. That's also one of my concerns. The differences between subsystems that all use an email-based review process can already be confusing, or just annoying to handle, especially when specific tools are mandated (the DRM dim tool or the ARM patch system come to mind). I dread to think about how painful it would be if one subsystem adopted gitlab, another one gerrit, ... That would also make changes that cross subsystem boundaries a nightmare to handle. Let's not forget that many developers are not confined within a single subsystem. On the other hand, I don't really see how switching the whole kernel to gitlab (or another system) could happen without frustrating a very large number of developers. We all know how conservative the community tend to be. One possible course of action would be to make the new tools optional and keep email as a common denominator. That way the old dinosaurs who won't adopt any tool introducing even the slightest disturbance in their work flow (it's not pleasant to realize that I may well be one of them) will still be able to work undisturbed, and all the other developers would be able to enjoy the myriad of amazing features offered by their tooling of choice. This would however put an extra burden on the new tools that would need to have first-class email compatibility. I don't know whether that would be feasible. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 20:15 ` Laurent Pinchart @ 2018-09-10 21:09 ` Sean Paul 2018-09-10 21:38 ` Laurent Pinchart 2018-09-11 8:44 ` Jani Nikula 1 sibling, 1 reply; 162+ messages in thread From: Sean Paul @ 2018-09-10 21:09 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James.Bottomley, ksummit-discuss On Mon, Sep 10, 2018 at 4:15 PM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote: > > On Mon, 10 Sep 2018, James Bottomley wrote: > > > 1. How do reviews happen? Non email projects tend to have only one > > > review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do > > > we want to pick a technology or allow multiple? I don't think this > > > is kernel wide, it could be a sybsystem choice. > > > > Yeah, but OTOH even now I've heard a lot of feedback about the irregular > > contributors / newcomers being confused by different subsystems having > > different processess and requirements; and those are basically just rather > > "minor" things currently (bugzilla usage, patchwork usage, subscriber-only > > mailinglists, etc), but it's still enough to confuse the hell out of > > people. > > That's also one of my concerns. The differences between subsystems that all > use an email-based review process can already be confusing, or just annoying > to handle, especially when specific tools are mandated (the DRM dim tool or > the ARM patch system come to mind). I dread to think about how painful it > would be if one subsystem adopted gitlab, another one gerrit, ... The other way to look at this is as a feature, not a bug. As mentioned upthread, each subsystem is essentially its own oss project at this point, so why keep pretending they're all the same thing? At least in the gitlab/gerrit/github nightmare, the differing contributing rules would be obvious as opposed to implicit as they are today. > That would > also make changes that cross subsystem boundaries a nightmare to handle. Let's > not forget that many developers are not confined within a single subsystem. Well, yeah, this kind of blows a hole in what I said above. I'm imagining Kees crying out in pain thinking about tree-wide changes in this new world :-). That said, there's probably a pretty good middle ground between what we have now and the gitlab utopia. Sean > > On the other hand, I don't really see how switching the whole kernel to gitlab > (or another system) could happen without frustrating a very large number of > developers. We all know how conservative the community tend to be. > > One possible course of action would be to make the new tools optional and keep > email as a common denominator. That way the old dinosaurs who won't adopt any > tool introducing even the slightest disturbance in their work flow (it's not > pleasant to realize that I may well be one of them) will still be able to work > undisturbed, and all the other developers would be able to enjoy the myriad of > amazing features offered by their tooling of choice. This would however put an > extra burden on the new tools that would need to have first-class email > compatibility. I don't know whether that would be feasible. > > -- > Regards, > > Laurent Pinchart > > > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:09 ` Sean Paul @ 2018-09-10 21:38 ` Laurent Pinchart 2018-09-11 10:06 ` Leon Romanovsky 0 siblings, 1 reply; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 21:38 UTC (permalink / raw) To: Sean Paul; +Cc: James.Bottomley, ksummit-discuss Hi Sean, On Tuesday, 11 September 2018 00:09:02 EEST Sean Paul wrote: > On Mon, Sep 10, 2018 at 4:15 PM Laurent Pinchart wrote: > > On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote: > >> On Mon, 10 Sep 2018, James Bottomley wrote: > >>> 1. How do reviews happen? Non email projects tend to have only one > >>> review mechanism (gerrit, github, gitlab, etc.) and stick to it. > >>> Do we want to pick a technology or allow multiple? I don't > >>> think this is kernel wide, it could be a sybsystem choice. > >> > >> Yeah, but OTOH even now I've heard a lot of feedback about the irregular > >> contributors / newcomers being confused by different subsystems having > >> different processess and requirements; and those are basically just > >> rather "minor" things currently (bugzilla usage, patchwork usage, > >> subscriber-only mailinglists, etc), but it's still enough to confuse the > >> hell out of people. > > > > That's also one of my concerns. The differences between subsystems that > > all use an email-based review process can already be confusing, or just > > annoying to handle, especially when specific tools are mandated (the DRM > > dim tool or the ARM patch system come to mind). I dread to think about > > how painful it would be if one subsystem adopted gitlab, another one > > gerrit, ... > > The other way to look at this is as a feature, not a bug. As mentioned > upthread, each subsystem is essentially its own oss project at this > point, so why keep pretending they're all the same thing? Subsystems are given lots of freedom in how they implement their development process, and many use that freedom, but in the end they are all integrated in the same kernel. This works because we have a common communication tool. > At least in the gitlab/gerrit/github nightmare, the differing contributing > rules would be obvious as opposed to implicit as they are today. And we would lose the common communication tool. (And if we went for gerrit, we'd likely lose the majority of developers, but that's a separate topic - after having to use gerrit when working on project Ara, I now reject any customer project that would force me to use gerrit again) > > That would also make changes that cross subsystem boundaries a nightmare > > to handle. Let's not forget that many developers are not confined within a > > single subsystem. > > Well, yeah, this kind of blows a hole in what I said above. I'm > imagining Kees crying out in pain thinking about tree-wide changes in > this new world :-). I had the exact same image :-) > That said, there's probably a pretty good middle ground between what > we have now and the gitlab utopia. I believe we all agree there's lots of room for improvement, that's already quite positive. > > On the other hand, I don't really see how switching the whole kernel to > > gitlab (or another system) could happen without frustrating a very large > > number of developers. We all know how conservative the community tend to > > be. > > > > One possible course of action would be to make the new tools optional and > > keep email as a common denominator. That way the old dinosaurs who won't > > adopt any tool introducing even the slightest disturbance in their work > > flow (it's not pleasant to realize that I may well be one of them) will > > still be able to work undisturbed, and all the other developers would be > > able to enjoy the myriad of amazing features offered by their tooling of > > choice. This would however put an extra burden on the new tools that > > would need to have first-class email compatibility. I don't know whether > > that would be feasible. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:38 ` Laurent Pinchart @ 2018-09-11 10:06 ` Leon Romanovsky 0 siblings, 0 replies; 162+ messages in thread From: Leon Romanovsky @ 2018-09-11 10:06 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James.Bottomley, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 4826 bytes --] On Tue, Sep 11, 2018 at 12:38:13AM +0300, Laurent Pinchart wrote: > Hi Sean, > > On Tuesday, 11 September 2018 00:09:02 EEST Sean Paul wrote: > > On Mon, Sep 10, 2018 at 4:15 PM Laurent Pinchart wrote: > > > On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote: > > >> On Mon, 10 Sep 2018, James Bottomley wrote: > > >>> 1. How do reviews happen? Non email projects tend to have only one > > >>> review mechanism (gerrit, github, gitlab, etc.) and stick to it. > > >>> Do we want to pick a technology or allow multiple? I don't > > >>> think this is kernel wide, it could be a sybsystem choice. > > >> > > >> Yeah, but OTOH even now I've heard a lot of feedback about the irregular > > >> contributors / newcomers being confused by different subsystems having > > >> different processess and requirements; and those are basically just > > >> rather "minor" things currently (bugzilla usage, patchwork usage, > > >> subscriber-only mailinglists, etc), but it's still enough to confuse the > > >> hell out of people. > > > > > > That's also one of my concerns. The differences between subsystems that > > > all use an email-based review process can already be confusing, or just > > > annoying to handle, especially when specific tools are mandated (the DRM > > > dim tool or the ARM patch system come to mind). I dread to think about > > > how painful it would be if one subsystem adopted gitlab, another one > > > gerrit, ... > > > > The other way to look at this is as a feature, not a bug. As mentioned > > upthread, each subsystem is essentially its own oss project at this > > point, so why keep pretending they're all the same thing? > > Subsystems are given lots of freedom in how they implement their development > process, and many use that freedom, but in the end they are all integrated in > the same kernel. This works because we have a common communication tool. > > > At least in the gitlab/gerrit/github nightmare, the differing contributing > > rules would be obvious as opposed to implicit as they are today. > > And we would lose the common communication tool. And not only communication tool, but educational tool. Reviews are performed by email visible to everyone and are supposed to be lesson-learned for other contributors. In opposite, gerrit-like tools favor one-to-one discussions. > > (And if we went for gerrit, we'd likely lose the majority of developers, but > that's a separate topic - after having to use gerrit when working on project > Ara, I now reject any customer project that would force me to use gerrit > again) As the one who suffers from internal gerrit and forced to use it, I fully agree with you and will add that we will lose most reviewers too, because it simply too much painful to follow and to do random review there. > > > > That would also make changes that cross subsystem boundaries a nightmare > > > to handle. Let's not forget that many developers are not confined within a > > > single subsystem. > > > > Well, yeah, this kind of blows a hole in what I said above. I'm > > imagining Kees crying out in pain thinking about tree-wide changes in > > this new world :-). > > I had the exact same image :-) I already suffer from it while submitting patches both to netdev and RDMA. The difference in coding style alone makes me nervous every time I get comment for such cross-subsystem patches. I'm pretty sure that it will be unbelievable hard to work in "multi-tool world". > > > That said, there's probably a pretty good middle ground between what > > we have now and the gitlab utopia. > > I believe we all agree there's lots of room for improvement, that's already > quite positive. > > > > On the other hand, I don't really see how switching the whole kernel to > > > gitlab (or another system) could happen without frustrating a very large > > > number of developers. We all know how conservative the community tend to > > > be. > > > > > > One possible course of action would be to make the new tools optional and > > > keep email as a common denominator. That way the old dinosaurs who won't > > > adopt any tool introducing even the slightest disturbance in their work > > > flow (it's not pleasant to realize that I may well be one of them) will > > > still be able to work undisturbed, and all the other developers would be > > > able to enjoy the myriad of amazing features offered by their tooling of > > > choice. This would however put an extra burden on the new tools that > > > would need to have first-class email compatibility. I don't know whether > > > that would be feasible. > > -- > Regards, > > Laurent Pinchart > > > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 20:15 ` Laurent Pinchart 2018-09-10 21:09 ` Sean Paul @ 2018-09-11 8:44 ` Jani Nikula 2018-09-11 9:08 ` Geert Uytterhoeven 1 sibling, 1 reply; 162+ messages in thread From: Jani Nikula @ 2018-09-11 8:44 UTC (permalink / raw) To: Laurent Pinchart, ksummit-discuss; +Cc: James Bottomley On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > That's also one of my concerns. The differences between subsystems that all > use an email-based review process can already be confusing, or just annoying > to handle, especially when specific tools are mandated (the DRM dim tool or > the ARM patch system come to mind). Note that you don't need to use dim unless you become a committer or a maintainer to a tree that's maintained using dim. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 8:44 ` Jani Nikula @ 2018-09-11 9:08 ` Geert Uytterhoeven 2018-09-11 10:01 ` Daniel Vetter 0 siblings, 1 reply; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-11 9:08 UTC (permalink / raw) To: Jani Nikula; +Cc: James Bottomley, ksummit-discuss On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote: > On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > That's also one of my concerns. The differences between subsystems that all > > use an email-based review process can already be confusing, or just annoying > > to handle, especially when specific tools are mandated (the DRM dim tool or > > the ARM patch system come to mind). > > Note that you don't need to use dim unless you become a committer or a > maintainer to a tree that's maintained using dim. Which unfortunately cannot be said about the ARM patch system... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 9:08 ` Geert Uytterhoeven @ 2018-09-11 10:01 ` Daniel Vetter 2018-09-11 10:09 ` Geert Uytterhoeven 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-11 10:01 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: James Bottomley, ksummit On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote: >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> > That's also one of my concerns. The differences between subsystems that all >> > use an email-based review process can already be confusing, or just annoying >> > to handle, especially when specific tools are mandated (the DRM dim tool or >> > the ARM patch system come to mind). >> >> Note that you don't need to use dim unless you become a committer or a >> maintainer to a tree that's maintained using dim. > > Which unfortunately cannot be said about the ARM patch system... Is there some docs about this ARM patch systems? Or just a link to what it is? I've never heard of it, until this thread here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 10:01 ` Daniel Vetter @ 2018-09-11 10:09 ` Geert Uytterhoeven 2018-09-11 10:17 ` Daniel Vetter 0 siblings, 1 reply; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-11 10:09 UTC (permalink / raw) To: Daniel Vetter; +Cc: James Bottomley, ksummit-discuss Hi Daniel, On Tue, Sep 11, 2018 at 12:01 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote: > >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > >> > That's also one of my concerns. The differences between subsystems that all > >> > use an email-based review process can already be confusing, or just annoying > >> > to handle, especially when specific tools are mandated (the DRM dim tool or > >> > the ARM patch system come to mind). > >> > >> Note that you don't need to use dim unless you become a committer or a > >> maintainer to a tree that's maintained using dim. > > > > Which unfortunately cannot be said about the ARM patch system... > > Is there some docs about this ARM patch systems? Or just a link to > what it is? I've never heard of it, until this thread here. http://www.arm.linux.org.uk/developer/patches/info.php It does take git-send-email patches, IFF they follow the rules. I've just discovered it's even linked to from Documentation/arm/README, which is horridly out-of-date (2.6? FTP?). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 10:09 ` Geert Uytterhoeven @ 2018-09-11 10:17 ` Daniel Vetter 2018-09-11 10:30 ` Geert Uytterhoeven 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-11 10:17 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: James Bottomley, ksummit On Tue, Sep 11, 2018 at 12:09 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, Sep 11, 2018 at 12:01 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >> On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven >> <geert@linux-m68k.org> wrote: >> > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote: >> >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> >> > That's also one of my concerns. The differences between subsystems that all >> >> > use an email-based review process can already be confusing, or just annoying >> >> > to handle, especially when specific tools are mandated (the DRM dim tool or >> >> > the ARM patch system come to mind). >> >> >> >> Note that you don't need to use dim unless you become a committer or a >> >> maintainer to a tree that's maintained using dim. >> > >> > Which unfortunately cannot be said about the ARM patch system... >> >> Is there some docs about this ARM patch systems? Or just a link to >> what it is? I've never heard of it, until this thread here. > > http://www.arm.linux.org.uk/developer/patches/info.php Thanks. > It does take git-send-email patches, IFF they follow the rules. > > I've just discovered it's even linked to from Documentation/arm/README, > which is horridly out-of-date (2.6? FTP?). >From a quick look: This is essentially another reimplementation of the patchwork idea (but probably predating that)? With the difference it's not all that accepting as patchwork, and it doesn't just automatically read a mailing list en-passant. Or am I off the mark? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 10:17 ` Daniel Vetter @ 2018-09-11 10:30 ` Geert Uytterhoeven 0 siblings, 0 replies; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-11 10:30 UTC (permalink / raw) To: Daniel Vetter; +Cc: James Bottomley, ksummit-discuss Hi Daniel, On Tue, Sep 11, 2018 at 12:17 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > On Tue, Sep 11, 2018 at 12:09 PM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > On Tue, Sep 11, 2018 at 12:01 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > >> On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven > >> <geert@linux-m68k.org> wrote: > >> > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote: > >> >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > >> >> > That's also one of my concerns. The differences between subsystems that all > >> >> > use an email-based review process can already be confusing, or just annoying > >> >> > to handle, especially when specific tools are mandated (the DRM dim tool or > >> >> > the ARM patch system come to mind). > >> >> > >> >> Note that you don't need to use dim unless you become a committer or a > >> >> maintainer to a tree that's maintained using dim. > >> > > >> > Which unfortunately cannot be said about the ARM patch system... > >> > >> Is there some docs about this ARM patch systems? Or just a link to > >> what it is? I've never heard of it, until this thread here. > > > > http://www.arm.linux.org.uk/developer/patches/info.php > > Thanks. > > > It does take git-send-email patches, IFF they follow the rules. > > > > I've just discovered it's even linked to from Documentation/arm/README, > > which is horridly out-of-date (2.6? FTP?). > > From a quick look: This is essentially another reimplementation of the > patchwork idea (but probably predating that)? With the difference it's > not all that accepting as patchwork, and it doesn't just automatically > read a mailing list en-passant. Or am I off the mark? That's correct. It is meant for reviewed patches only. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:13 ` Jiri Kosina ` (2 preceding siblings ...) 2018-09-10 20:15 ` Laurent Pinchart @ 2018-09-11 8:41 ` Jani Nikula 3 siblings, 0 replies; 162+ messages in thread From: Jani Nikula @ 2018-09-11 8:41 UTC (permalink / raw) To: Jiri Kosina, James Bottomley; +Cc: ksummit On Mon, 10 Sep 2018, Jiri Kosina <jikos@kernel.org> wrote: > On Mon, 10 Sep 2018, James Bottomley wrote: > >> 1. How do reviews happen? Non email projects tend to have only one >> review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do >> we want to pick a technology or allow multiple? I don't think this >> is kernel wide, it could be a sybsystem choice. > > Yeah, but OTOH even now I've heard a lot of feedback about the irregular > contributors / newcomers being confused by different subsystems having > different processess and requirements; and those are basically just rather > "minor" things currently (bugzilla usage, patchwork usage, subscriber-only > mailinglists, etc), but it's still enough to confuse the hell out of > people. MAINTAINERS is supposed to be the central database about all this. IMO maintainers should be more active in getting their data updated. We have folks who don't document their preferences or expectations, at all, and then go on to rant at random contributors about how their corner of the kernel community is supposed to operate. For example, that they never look at bugzilla etc. If the current entries don't cover everything, one can use W: to add a link to more details, or we can add new entries. And that's just the obvious prerequisite to actively telling contributors to look at MAINTAINERS. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 14:53 ` Linus Torvalds 2018-09-10 15:08 ` James Bottomley @ 2018-09-10 15:31 ` Daniel Vetter 2018-09-10 16:39 ` Olof Johansson ` (2 more replies) 2018-09-10 15:56 ` Daniel Vetter ` (3 subsequent siblings) 5 siblings, 3 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 15:31 UTC (permalink / raw) To: Linus Torvalds; +Cc: ksummit 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 <torvalds@linux-foundation.org> 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:31 ` Daniel Vetter @ 2018-09-10 16:39 ` Olof Johansson 2018-09-10 17:10 ` Daniel Vetter 2018-09-12 18:59 ` Darren Hart 2018-09-13 2:56 ` Theodore Y. Ts'o 2 siblings, 1 reply; 162+ messages in thread From: Olof Johansson @ 2018-09-10 16:39 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> 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 > <torvalds@linux-foundation.org> 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. 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 ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 16:39 ` Olof Johansson @ 2018-09-10 17:10 ` Daniel Vetter 2018-09-12 19:02 ` Darren Hart 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 17:10 UTC (permalink / raw) To: Olof Johansson; +Cc: ksummit On Mon, Sep 10, 2018 at 6:39 PM, Olof Johansson <olof@lixom.net> wrote: > On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> 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 >> <torvalds@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 17:10 ` Daniel Vetter @ 2018-09-12 19:02 ` Darren Hart 0 siblings, 0 replies; 162+ messages in thread From: Darren Hart @ 2018-09-12 19:02 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit On Mon, Sep 10, 2018 at 07:10:58PM +0200, Daniel Vetter wrote: > On Mon, Sep 10, 2018 at 6:39 PM, Olof Johansson <olof@lixom.net> wrote: > > On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: ... > > 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 > :-) This sounds really useful to me. -- Darren Hart VMware Open Source Technology Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:31 ` Daniel Vetter 2018-09-10 16:39 ` Olof Johansson @ 2018-09-12 18:59 ` Darren Hart 2018-09-12 20:05 ` Daniel Vetter 2018-09-13 2:56 ` Theodore Y. Ts'o 2 siblings, 1 reply; 162+ messages in thread From: Darren Hart @ 2018-09-12 18:59 UTC (permalink / raw) To: Daniel Vetter, Andy Shevchenko; +Cc: ksummit 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 > <torvalds@linux-foundation.org> 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 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. 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. -- Darren Hart VMware Open Source Technology Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 18:59 ` Darren Hart @ 2018-09-12 20:05 ` Daniel Vetter 2018-09-12 20:58 ` Darren Hart 2018-09-13 11:27 ` Mark Brown 0 siblings, 2 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-12 20:05 UTC (permalink / raw) To: Darren Hart; +Cc: Andy Shevchenko, ksummit On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> 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 >> <torvalds@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 20:05 ` Daniel Vetter @ 2018-09-12 20:58 ` Darren Hart 2018-09-13 11:27 ` Mark Brown 1 sibling, 0 replies; 162+ messages in thread From: Darren Hart @ 2018-09-12 20:58 UTC (permalink / raw) To: Daniel Vetter; +Cc: Andy Shevchenko, ksummit On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote: > On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> 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 > >> <torvalds@linux-foundation.org> 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 The merge-config script reports on this when you include a .config, e.g. $ make defconfig pdx86.config > 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. I'm working on config fragment howto talk for OSS EU which I hope to include some targeted config fuzz testing in. I hope to have a more fleshed out story on how work with this by then. > > 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. Agree - this idea has been circling around with a number of people generally supporting the idea, but none of us has made the time to try it yet. I'd be interested in a set of subsystem maintainers willing to collaborate and try it out. > > 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 > -- Darren Hart VMware Open Source Technology Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 20:05 ` Daniel Vetter 2018-09-12 20:58 ` Darren Hart @ 2018-09-13 11:27 ` Mark Brown 2018-09-13 11:41 ` Daniel Vetter 1 sibling, 1 reply; 162+ messages in thread From: Mark Brown @ 2018-09-13 11:27 UTC (permalink / raw) To: Daniel Vetter; +Cc: Andy Shevchenko, ksummit [-- Attachment #1: Type: text/plain, Size: 1085 bytes --] On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote: > On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote: > > 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 Yes, I've got a script like that as well (mine's a *tiny* bit less sophisticated) - it's super handy if you frequently add new drivers. > Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig > seems to do this, including enabling (all?) dependencies you need. That only works for dependencies that are selected, if there's a config option that stops CONFIG_FOO being seen by the user (eg, having MFD_FOO preventing SUBSYSTEM_FOO being enabled) then it'll just get silently ignored. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 11:27 ` Mark Brown @ 2018-09-13 11:41 ` Daniel Vetter 2018-09-13 17:08 ` Darren Hart 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-13 11:41 UTC (permalink / raw) To: Mark Brown; +Cc: Andy Shevchenko, ksummit On Thu, Sep 13, 2018 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote: > On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote: >> On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote: > >> > 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 > > Yes, I've got a script like that as well (mine's a *tiny* bit less > sophisticated) - it's super handy if you frequently add new drivers. > >> Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig >> seems to do this, including enabling (all?) dependencies you need. > > That only works for dependencies that are selected, if there's a config > option that stops CONFIG_FOO being seen by the user (eg, having MFD_FOO > preventing SUBSYSTEM_FOO being enabled) then it'll just get silently > ignored. I guess I fumbled something with my testing, this does indeed not work like I hoped :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 11:41 ` Daniel Vetter @ 2018-09-13 17:08 ` Darren Hart 0 siblings, 0 replies; 162+ messages in thread From: Darren Hart @ 2018-09-13 17:08 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit, Andy Shevchenko On Thu, Sep 13, 2018 at 01:41:26PM +0200, Daniel Vetter wrote: > On Thu, Sep 13, 2018 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote: > > On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote: > >> On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote: > > > >> > 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 > > > > Yes, I've got a script like that as well (mine's a *tiny* bit less > > sophisticated) - it's super handy if you frequently add new drivers. > > > >> Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig > >> seems to do this, including enabling (all?) dependencies you need. > > > > That only works for dependencies that are selected, if there's a config > > option that stops CONFIG_FOO being seen by the user (eg, having MFD_FOO > > preventing SUBSYSTEM_FOO being enabled) then it'll just get silently > > ignored. > > I guess I fumbled something with my testing, this does indeed not work > like I hoped :-/ merge-config will tell you if the CONFIG_* you specified differs in the resulting .config. e.g. $ ls arch/x86/configs/pd* arch/x86/configs/pdx86-mods.config $ make defconfig pdx86-mods.config *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # Using .config as base Merging ./arch/x86/configs/pdx86-mods.config Value of CONFIG_MELLANOX_PLATFORM is redefined by fragment ./arch/x86/configs/pdx86-mods.config: Previous value: # CONFIG_MELLANOX_PLATFORM is not set New value: CONFIG_MELLANOX_PLATFORM=y Value of CONFIG_ACER_WIRELESS is redefined by fragment ./arch/x86/configs/pdx86-mods.config: Previous value: # CONFIG_ACER_WIRELESS is not set New value: CONFIG_ACER_WIRELESS=m ... -- Darren Hart VMware Open Source Technology Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:31 ` Daniel Vetter 2018-09-10 16:39 ` Olof Johansson 2018-09-12 18:59 ` Darren Hart @ 2018-09-13 2:56 ` Theodore Y. Ts'o 2018-09-13 5:17 ` Daniel Vetter 2 siblings, 1 reply; 162+ messages in thread From: Theodore Y. Ts'o @ 2018-09-13 2:56 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote: > > 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. I wonder if this is something that would be better done at the Kernel Summit (e.g., in Vancouver), as a discussion session. It's important to remember that Maintainer's Summit has (by design) a small number of attendees. If the goal is to compare notes about various experiments, it's likely there will be many kernel developers present in Vancouver. After all, getting input from just "Maintainers" but all developers participating in development process would be valuable. - Ted ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 2:56 ` Theodore Y. Ts'o @ 2018-09-13 5:17 ` Daniel Vetter 0 siblings, 0 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-13 5:17 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: ksummit On Thu, Sep 13, 2018 at 4:56 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote: >> >> 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. > > I wonder if this is something that would be better done at the Kernel > Summit (e.g., in Vancouver), as a discussion session. It's important > to remember that Maintainer's Summit has (by design) a small number of > attendees. If the goal is to compare notes about various experiments, > it's likely there will be many kernel developers present in Vancouver. > After all, getting input from just "Maintainers" but all developers > participating in development process would be valuable. Yes, that was at least my idea for all of these topics. I wasn't sure what label to pick since it's not really a tech topic either. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 14:53 ` Linus Torvalds 2018-09-10 15:08 ` James Bottomley 2018-09-10 15:31 ` Daniel Vetter @ 2018-09-10 15:56 ` Daniel Vetter 2018-09-10 20:32 ` Laurent Pinchart 2018-09-10 16:29 ` [Ksummit-discuss] Fwd: " Daniel Vetter ` (2 subsequent siblings) 5 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 15:56 UTC (permalink / raw) To: Linus Torvalds; +Cc: ksummit On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >> - Assuming it gets accepted I think my LPC talk on "migrating to >> gitlab" will raise some questions, and probably overflow into hallway >> track or a BOF session. First a bit more context: This is a different talk than the other "stuff drm people are doing" talks I've done in the past: We haven't done anything yet. We haven't even really started planning the migration yet :-) The idea here was that for once I don't do a talk when it's all done, but way ahead of that when we're still figuring things out. The underlying reason for the migration is that fd.o admins want to shut down their home-grown collage of services and replace it with something that's much easier to maintain, provides solid 2FA and allows them to offload a lot of the admin work (handing out access rights and stuff) to all the projects their hosting. Plus stop the shell access services, if that's ever possible. So right now this is only about moving the git server from one place to the other. And we haven't even done the full plan for that migration (it's a pile of repos and stuff). So really very early. But now that we do have this modern thing, a lot of people are looking into all the shiny features it offers, and trying to figure out whether they're useful for us or not. And that's what I want to go through in the talk - the title is a bit on the clickbait side :-) > I've not used gitlab personally, but I *have* used github for a much > smaller project. > > I have to say, the random and relaxed model is enjoyable. I can see > how somebody coming from that, then finds the strict kernel rules (and > _different_ rules for different parts) off-putting and confusing. > > At the same time, I have to say that people need to keep in mind that > the kernel is *different*. We're not a small project with five > developers that isn't all that critical. Some of our off-putting > development models are there for a very very good reason. I think a > lot of people who find the kernel unfriendly just don't appreciate > that part. > > The kernel used to be pretty free-wheeling too. 20+ years ago. What I definitely don't want is a free-wheeling thing a la your standard github repo. There's also the issue that github massively optimizes for small projects in their entire setup. I've done a blog post about that a while ago and chatted with a bunch of githubbers, they're really not interested in big-project workflows that much. gitlab otoh is very interested in that, and they picked up some of the concepts around how we use topic branches and pull requests in the kernel. It's by far not all implemented yet, but a lot more promising than anything else I've looked at. And we can always just keep using our existing tooling ofc. Aside from this there's a bunch of other reasons fd.o admins picked gitlab (against other contenders they checked out), but this is one of the big ones. At least from the kernel's pov. For anyone bored enough, here's the full details of the why from fd.o admins: https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > And I still hate how github ends up making it really really easy to > make horribly bad commit messages, and it encourages a "just rebase on > top of the integration branch" model, and I do not believe that it > would ever work for the kernel at large. Too much room for chaos. > > BUT. > > I do think it's still instructive to look at how those "fun small > projects" work. Having the whole web interface and a more relaxed > setup is a good thing. And it's probably *better* than the strict > rules when you don't really need those strict rules. > > So I do believe that it could work for a subsystem. Because "too much > room for chaos" ends up being nice when you don't want to worry about > the proper channels etc. > > For example, we've had the "trivial tree", which tends to be a really > thankless project, that might well be managed way more easily by just > having a random tree that lots of people can commit to, and we could > even encourage the github (gitlab?) model of random non-kernel people > just sending their random trees to it, and have then the group of > committers be able to merge the changes (and at least on github, the > default merge is just a fast-forward, so it actually acts more like a > patch queue than a git tree). Yeah, the trivial/"fun first contributions" process is a lot more polished on many of these projects, and there's a bunch such things we kinda want to look into longer-term. And this really is all long-term, because just the initial git server migration most likely won't even start until next year. A much bigger thing for us is CI integration. patchwork + patch bombs + lots of tears and gin do kinda work, but it's super painful and a real chaos no one has any overview over. gitlab has really neat integrated CI for anything that you can run on containers/virtual machines (already played with it, pretty dope, and I have 0 clue about this docker/container stuff). And also seems to have good support to tie all kinds of exterrnal CI validation into pull requests (well gitlab calls them merge requests, it's the same). One thing we're at least planning to experiment with is to take the driver pull requests from drm, auto-convert them into gitlab merge requests (or just ask people to directly do that), and then let to bots go wild. Would give us a nice single point where you can check all the information from all the different checks and vendor CI and everything. Not even that much with the goal to do the merge using the web ui, just to integrate all the testing and validation in one spot. > And the reason I mention the trivial tree is not because the trivial > tree itself is all that interesting or because I'd like to belittle > that model ("that will only work for trivial unimportant stuff"), but > because it might be a good area to experiment in, and a way to get > people used to the flow. > > Because if somebody is willing to every once in a while look at > trivial tree pull requests and merge them to the trivial tree, maybe > that person will start using the same flow for their "real" work. > > And I do think that "patches by email" doesn't scale. I've been there, > done that, and I got the T-shirt. > > I used tools that some people absolutely hated to get out of that > rat-hole. When that failed, I had to write my own. > > So I very much do think that email doesn't really work at scale. > > But I know the kernel people who still do real development (as opposed > to me) work that way. > > So let me suggest a topic for the maintainer summit: > > "Live without email - possible?" > > just to get that ball rolling I'd say "nope", even with the s/live/patches/. Definitely not for anything spanning subsystems. Even within gitlabd the cross-tree support is not (yet) there. And we definitely need to have a solid gitlab/mailing list gateway, which is somewhere on the huge list of things fd.o admins need to do. It exists, but SMTP is pain, and fd.o is volunteer run, so all takes time. And then the gateway might be too much garbage to be useful. 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. Whether anything of this will make it into the production drm processes, no idea. "maybe" is the best answer at this time I think. And yes I hope that by LPC I'll have a bit more solid understanding of how this gitlab thing works and what we could try out, so this isn't as much high-level gossipping as it is right now :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 15:56 ` Daniel Vetter @ 2018-09-10 20:32 ` Laurent Pinchart 2018-09-10 20:55 ` Daniel Vetter ` (2 more replies) 0 siblings, 3 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 20:32 UTC (permalink / raw) To: ksummit-discuss On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote: > On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote: > > On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote: > >> - Assuming it gets accepted I think my LPC talk on "migrating to > >> gitlab" will raise some questions, and probably overflow into hallway > >> track or a BOF session. > > First a bit more context: This is a different talk than the other > "stuff drm people are doing" talks I've done in the past: We haven't > done anything yet. We haven't even really started planning the > migration yet :-) > > The idea here was that for once I don't do a talk when it's all done, > but way ahead of that when we're still figuring things out. The > underlying reason for the migration is that fd.o admins want to shut > down their home-grown collage of services and replace it with > something that's much easier to maintain, provides solid 2FA and > allows them to offload a lot of the admin work (handing out access > rights and stuff) to all the projects their hosting. Plus stop the > shell access services, if that's ever possible. > > So right now this is only about moving the git server from one place > to the other. And we haven't even done the full plan for that > migration (it's a pile of repos and stuff). So really very early. But > now that we do have this modern thing, a lot of people are looking > into all the shiny features it offers, and trying to figure out > whether they're useful for us or not. And that's what I want to go > through in the talk - the title is a bit on the clickbait side :-) > > > I've not used gitlab personally, but I *have* used github for a much > > smaller project. > > > > I have to say, the random and relaxed model is enjoyable. I can see > > how somebody coming from that, then finds the strict kernel rules (and > > _different_ rules for different parts) off-putting and confusing. > > > > At the same time, I have to say that people need to keep in mind that > > the kernel is *different*. We're not a small project with five > > developers that isn't all that critical. Some of our off-putting > > development models are there for a very very good reason. I think a > > lot of people who find the kernel unfriendly just don't appreciate > > that part. > > > > The kernel used to be pretty free-wheeling too. 20+ years ago. > > What I definitely don't want is a free-wheeling thing a la your > standard github repo. There's also the issue that github massively > optimizes for small projects in their entire setup. I've done a blog > post about that a while ago and chatted with a bunch of githubbers, > they're really not interested in big-project workflows that much. > > gitlab otoh is very interested in that, and they picked up some of the > concepts around how we use topic branches and pull requests in the > kernel. It's by far not all implemented yet, but a lot more promising > than anything else I've looked at. And we can always just keep using > our existing tooling ofc. > > Aside from this there's a bunch of other reasons fd.o admins picked > gitlab (against other contenders they checked out), but this is one of > the big ones. At least from the kernel's pov. For anyone bored enough, > here's the full details of the why from fd.o admins: > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > > And I still hate how github ends up making it really really easy to > > make horribly bad commit messages, and it encourages a "just rebase on > > top of the integration branch" model, and I do not believe that it > > would ever work for the kernel at large. Too much room for chaos. > > > > BUT. > > > > I do think it's still instructive to look at how those "fun small > > projects" work. Having the whole web interface and a more relaxed > > setup is a good thing. And it's probably *better* than the strict > > rules when you don't really need those strict rules. > > > > So I do believe that it could work for a subsystem. Because "too much > > room for chaos" ends up being nice when you don't want to worry about > > the proper channels etc. > > > > For example, we've had the "trivial tree", which tends to be a really > > thankless project, that might well be managed way more easily by just > > having a random tree that lots of people can commit to, and we could > > even encourage the github (gitlab?) model of random non-kernel people > > just sending their random trees to it, and have then the group of > > committers be able to merge the changes (and at least on github, the > > default merge is just a fast-forward, so it actually acts more like a > > patch queue than a git tree). > > Yeah, the trivial/"fun first contributions" process is a lot more > polished on many of these projects, and there's a bunch such things we > kinda want to look into longer-term. And this really is all long-term, > because just the initial git server migration most likely won't even > start until next year. > > A much bigger thing for us is CI integration. patchwork + patch bombs > + lots of tears and gin do kinda work, but it's super painful and a > real chaos no one has any overview over. gitlab has really neat > integrated CI for anything that you can run on containers/virtual > machines (already played with it, pretty dope, and I have 0 clue about > this docker/container stuff). And also seems to have good support to > tie all kinds of exterrnal CI validation into pull requests (well > gitlab calls them merge requests, it's the same). > > One thing we're at least planning to experiment with is to take the > driver pull requests from drm, auto-convert them into gitlab merge > requests (or just ask people to directly do that), and then let to > bots go wild. Would give us a nice single point where you can check > all the information from all the different checks and vendor CI and > everything. Not even that much with the goal to do the merge using the > web ui, just to integrate all the testing and validation in one spot. > > > And the reason I mention the trivial tree is not because the trivial > > tree itself is all that interesting or because I'd like to belittle > > that model ("that will only work for trivial unimportant stuff"), but > > because it might be a good area to experiment in, and a way to get > > people used to the flow. > > > > Because if somebody is willing to every once in a while look at > > trivial tree pull requests and merge them to the trivial tree, maybe > > that person will start using the same flow for their "real" work. > > > > And I do think that "patches by email" doesn't scale. I've been there, > > done that, and I got the T-shirt. > > > > I used tools that some people absolutely hated to get out of that > > rat-hole. When that failed, I had to write my own. > > > > So I very much do think that email doesn't really work at scale. > > > > But I know the kernel people who still do real development (as opposed > > to me) work that way. > > > > So let me suggest a topic for the maintainer summit: > > "Live without email - possible?" > > > > just to get that ball rolling > > I'd say "nope", even with the s/live/patches/. Definitely not for > anything spanning subsystems. Even within gitlabd the cross-tree > support is not (yet) there. And we definitely need to have a solid > gitlab/mailing list gateway, which is somewhere on the huge list of > things fd.o admins need to do. It exists, but SMTP is pain, and fd.o > is volunteer run, so all takes time. And then the gateway might be too > much garbage to be useful. I believe we need a common communication system that is supported by all subsystems. Today that system is email. If we don't want to challenge that, we'll need first-class compatibility between whatever new tool we introduce and email, in both direction. All discussions, including patch review, happening through other means (web UI for instance) will need to be pushed to emails, and email replies will need to be integrated back into the system, in such a way that will not completely mess up the formatting and communication flow. It has to be transparent enough. If we want to challenge that, we'll have to agree about another communication system for the whole kernel. While I don't think that's realistic, I'm not opposed to discussing it. However, I expect many developers to come up with lists of requirements, and the result of merging all those requirements together to be exactly email and nothing else :-) On my side, there are three very important features that a communication system should have: - It should be push-based. I don't want to have to log in and pull information from web UIs. - It should be customizable, offering an easy way to script review, and patch and pull request handling. - It should offer an offline mode. Lots of us travel a lot or generally have to work without an internet connection more often than we would like, so any solution that requires being online won't work. Emails provide all that, there may be good options I just fail to think about right now. > 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. > Whether anything of this will make it into the production drm > processes, no idea. "maybe" is the best answer at this time I think. > > And yes I hope that by LPC I'll have a bit more solid understanding of > how this gitlab thing works and what we could try out, so this isn't > as much high-level gossipping as it is right now :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 20:32 ` Laurent Pinchart @ 2018-09-10 20:55 ` Daniel Vetter 2018-09-10 21:33 ` Laurent Pinchart 2018-09-10 21:11 ` Theodore Y. Ts'o 2018-09-10 21:19 ` Konstantin Ryabitsev 2 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 20:55 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote: >> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote: >> > On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote: >> >> - Assuming it gets accepted I think my LPC talk on "migrating to >> >> gitlab" will raise some questions, and probably overflow into hallway >> >> track or a BOF session. >> >> First a bit more context: This is a different talk than the other >> "stuff drm people are doing" talks I've done in the past: We haven't >> done anything yet. We haven't even really started planning the >> migration yet :-) >> >> The idea here was that for once I don't do a talk when it's all done, >> but way ahead of that when we're still figuring things out. The >> underlying reason for the migration is that fd.o admins want to shut >> down their home-grown collage of services and replace it with >> something that's much easier to maintain, provides solid 2FA and >> allows them to offload a lot of the admin work (handing out access >> rights and stuff) to all the projects their hosting. Plus stop the >> shell access services, if that's ever possible. >> >> So right now this is only about moving the git server from one place >> to the other. And we haven't even done the full plan for that >> migration (it's a pile of repos and stuff). So really very early. But >> now that we do have this modern thing, a lot of people are looking >> into all the shiny features it offers, and trying to figure out >> whether they're useful for us or not. And that's what I want to go >> through in the talk - the title is a bit on the clickbait side :-) >> >> > I've not used gitlab personally, but I *have* used github for a much >> > smaller project. >> > >> > I have to say, the random and relaxed model is enjoyable. I can see >> > how somebody coming from that, then finds the strict kernel rules (and >> > _different_ rules for different parts) off-putting and confusing. >> > >> > At the same time, I have to say that people need to keep in mind that >> > the kernel is *different*. We're not a small project with five >> > developers that isn't all that critical. Some of our off-putting >> > development models are there for a very very good reason. I think a >> > lot of people who find the kernel unfriendly just don't appreciate >> > that part. >> > >> > The kernel used to be pretty free-wheeling too. 20+ years ago. >> >> What I definitely don't want is a free-wheeling thing a la your >> standard github repo. There's also the issue that github massively >> optimizes for small projects in their entire setup. I've done a blog >> post about that a while ago and chatted with a bunch of githubbers, >> they're really not interested in big-project workflows that much. >> >> gitlab otoh is very interested in that, and they picked up some of the >> concepts around how we use topic branches and pull requests in the >> kernel. It's by far not all implemented yet, but a lot more promising >> than anything else I've looked at. And we can always just keep using >> our existing tooling ofc. >> >> Aside from this there's a bunch of other reasons fd.o admins picked >> gitlab (against other contenders they checked out), but this is one of >> the big ones. At least from the kernel's pov. For anyone bored enough, >> here's the full details of the why from fd.o admins: >> >> https://www.fooishbar.org/blog/gitlab-fdo-introduction/ >> >> > And I still hate how github ends up making it really really easy to >> > make horribly bad commit messages, and it encourages a "just rebase on >> > top of the integration branch" model, and I do not believe that it >> > would ever work for the kernel at large. Too much room for chaos. >> > >> > BUT. >> > >> > I do think it's still instructive to look at how those "fun small >> > projects" work. Having the whole web interface and a more relaxed >> > setup is a good thing. And it's probably *better* than the strict >> > rules when you don't really need those strict rules. >> > >> > So I do believe that it could work for a subsystem. Because "too much >> > room for chaos" ends up being nice when you don't want to worry about >> > the proper channels etc. >> > >> > For example, we've had the "trivial tree", which tends to be a really >> > thankless project, that might well be managed way more easily by just >> > having a random tree that lots of people can commit to, and we could >> > even encourage the github (gitlab?) model of random non-kernel people >> > just sending their random trees to it, and have then the group of >> > committers be able to merge the changes (and at least on github, the >> > default merge is just a fast-forward, so it actually acts more like a >> > patch queue than a git tree). >> >> Yeah, the trivial/"fun first contributions" process is a lot more >> polished on many of these projects, and there's a bunch such things we >> kinda want to look into longer-term. And this really is all long-term, >> because just the initial git server migration most likely won't even >> start until next year. >> >> A much bigger thing for us is CI integration. patchwork + patch bombs >> + lots of tears and gin do kinda work, but it's super painful and a >> real chaos no one has any overview over. gitlab has really neat >> integrated CI for anything that you can run on containers/virtual >> machines (already played with it, pretty dope, and I have 0 clue about >> this docker/container stuff). And also seems to have good support to >> tie all kinds of exterrnal CI validation into pull requests (well >> gitlab calls them merge requests, it's the same). >> >> One thing we're at least planning to experiment with is to take the >> driver pull requests from drm, auto-convert them into gitlab merge >> requests (or just ask people to directly do that), and then let to >> bots go wild. Would give us a nice single point where you can check >> all the information from all the different checks and vendor CI and >> everything. Not even that much with the goal to do the merge using the >> web ui, just to integrate all the testing and validation in one spot. >> >> > And the reason I mention the trivial tree is not because the trivial >> > tree itself is all that interesting or because I'd like to belittle >> > that model ("that will only work for trivial unimportant stuff"), but >> > because it might be a good area to experiment in, and a way to get >> > people used to the flow. >> > >> > Because if somebody is willing to every once in a while look at >> > trivial tree pull requests and merge them to the trivial tree, maybe >> > that person will start using the same flow for their "real" work. >> > >> > And I do think that "patches by email" doesn't scale. I've been there, >> > done that, and I got the T-shirt. >> > >> > I used tools that some people absolutely hated to get out of that >> > rat-hole. When that failed, I had to write my own. >> > >> > So I very much do think that email doesn't really work at scale. >> > >> > But I know the kernel people who still do real development (as opposed >> > to me) work that way. >> > >> > So let me suggest a topic for the maintainer summit: >> > "Live without email - possible?" >> > >> > just to get that ball rolling >> >> I'd say "nope", even with the s/live/patches/. Definitely not for >> anything spanning subsystems. Even within gitlabd the cross-tree >> support is not (yet) there. And we definitely need to have a solid >> gitlab/mailing list gateway, which is somewhere on the huge list of >> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o >> is volunteer run, so all takes time. And then the gateway might be too >> much garbage to be useful. > > I believe we need a common communication system that is supported by all > subsystems. Today that system is email. > > If we don't want to challenge that, we'll need first-class compatibility > between whatever new tool we introduce and email, in both direction. All > discussions, including patch review, happening through other means (web UI for > instance) will need to be pushed to emails, and email replies will need to be > integrated back into the system, in such a way that will not completely mess > up the formatting and communication flow. It has to be transparent enough. > > If we want to challenge that, we'll have to agree about another communication > system for the whole kernel. While I don't think that's realistic, I'm not > opposed to discussing it. However, I expect many developers to come up with > lists of requirements, and the result of merging all those requirements > together to be exactly email and nothing else :-) > > On my side, there are three very important features that a communication > system should have: > > - It should be push-based. I don't want to have to log in and pull information > from web UIs. > > - It should be customizable, offering an easy way to script review, and patch > and pull request handling. > > - It should offer an offline mode. Lots of us travel a lot or generally have > to work without an internet connection more often than we would like, so any > solution that requires being online won't work. > > Emails provide all that, there may be good options I just fail to think about > right now. Thanks for your list, "figuring out what we need from email to evaluate the usefulness of the gitlab gateway" was somewhere on my todo :-) More seriously: We're _really_ not far beyond the "hey, what about gitlab" stage of this entire discussions. As mentioned, I have not much answers, much less a plan, right now. The mail goal here is just to figure out the right questions (and then hopefully have some useful progress to report at LPC already). >> 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. - 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. - 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 :-) Aside: If you want to be involved in the nitty gritty details (aka lots of boring fd.o admin discussions), here's the overall migration tracking task: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69 >> Whether anything of this will make it into the production drm >> processes, no idea. "maybe" is the best answer at this time I think. >> >> And yes I hope that by LPC I'll have a bit more solid understanding of >> how this gitlab thing works and what we could try out, so this isn't >> as much high-level gossipping as it is right now :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 20:55 ` Daniel Vetter @ 2018-09-10 21:33 ` Laurent Pinchart 2018-09-10 22:44 ` Daniel Vetter 2018-09-10 22:56 ` Laurent Pinchart 0 siblings, 2 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 21:33 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit Hi Daniel, 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: > >> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote: > >>> On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote: > >>>> - Assuming it gets accepted I think my LPC talk on "migrating to > >>>> gitlab" will raise some questions, and probably overflow into hallway > >>>> track or a BOF session. > >> > >> First a bit more context: This is a different talk than the other > >> "stuff drm people are doing" talks I've done in the past: We haven't > >> done anything yet. We haven't even really started planning the > >> migration yet :-) > >> > >> The idea here was that for once I don't do a talk when it's all done, > >> but way ahead of that when we're still figuring things out. The > >> underlying reason for the migration is that fd.o admins want to shut > >> down their home-grown collage of services and replace it with > >> something that's much easier to maintain, provides solid 2FA and > >> allows them to offload a lot of the admin work (handing out access > >> rights and stuff) to all the projects their hosting. Plus stop the > >> shell access services, if that's ever possible. > >> > >> So right now this is only about moving the git server from one place > >> to the other. And we haven't even done the full plan for that > >> migration (it's a pile of repos and stuff). So really very early. But > >> now that we do have this modern thing, a lot of people are looking > >> into all the shiny features it offers, and trying to figure out > >> whether they're useful for us or not. And that's what I want to go > >> through in the talk - the title is a bit on the clickbait side :-) > >> > >>> I've not used gitlab personally, but I *have* used github for a much > >>> smaller project. > >>> > >>> I have to say, the random and relaxed model is enjoyable. I can see > >>> how somebody coming from that, then finds the strict kernel rules (and > >>> _different_ rules for different parts) off-putting and confusing. > >>> > >>> At the same time, I have to say that people need to keep in mind that > >>> the kernel is *different*. We're not a small project with five > >>> developers that isn't all that critical. Some of our off-putting > >>> development models are there for a very very good reason. I think a > >>> lot of people who find the kernel unfriendly just don't appreciate > >>> that part. > >>> > >>> The kernel used to be pretty free-wheeling too. 20+ years ago. > >> > >> What I definitely don't want is a free-wheeling thing a la your > >> standard github repo. There's also the issue that github massively > >> optimizes for small projects in their entire setup. I've done a blog > >> post about that a while ago and chatted with a bunch of githubbers, > >> they're really not interested in big-project workflows that much. > >> > >> gitlab otoh is very interested in that, and they picked up some of the > >> concepts around how we use topic branches and pull requests in the > >> kernel. It's by far not all implemented yet, but a lot more promising > >> than anything else I've looked at. And we can always just keep using > >> our existing tooling ofc. > >> > >> Aside from this there's a bunch of other reasons fd.o admins picked > >> gitlab (against other contenders they checked out), but this is one of > >> the big ones. At least from the kernel's pov. For anyone bored enough, > >> here's the full details of the why from fd.o admins: > >> > >> https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > >> > >>> And I still hate how github ends up making it really really easy to > >>> make horribly bad commit messages, and it encourages a "just rebase on > >>> top of the integration branch" model, and I do not believe that it > >>> would ever work for the kernel at large. Too much room for chaos. > >>> > >>> BUT. > >>> > >>> I do think it's still instructive to look at how those "fun small > >>> projects" work. Having the whole web interface and a more relaxed > >>> setup is a good thing. And it's probably *better* than the strict > >>> rules when you don't really need those strict rules. > >>> > >>> So I do believe that it could work for a subsystem. Because "too much > >>> room for chaos" ends up being nice when you don't want to worry about > >>> the proper channels etc. > >>> > >>> For example, we've had the "trivial tree", which tends to be a really > >>> thankless project, that might well be managed way more easily by just > >>> having a random tree that lots of people can commit to, and we could > >>> even encourage the github (gitlab?) model of random non-kernel people > >>> just sending their random trees to it, and have then the group of > >>> committers be able to merge the changes (and at least on github, the > >>> default merge is just a fast-forward, so it actually acts more like a > >>> patch queue than a git tree). > >> > >> Yeah, the trivial/"fun first contributions" process is a lot more > >> polished on many of these projects, and there's a bunch such things we > >> kinda want to look into longer-term. And this really is all long-term, > >> because just the initial git server migration most likely won't even > >> start until next year. > >> > >> A much bigger thing for us is CI integration. patchwork + patch bombs > >> + lots of tears and gin do kinda work, but it's super painful and a > >> real chaos no one has any overview over. gitlab has really neat > >> integrated CI for anything that you can run on containers/virtual > >> machines (already played with it, pretty dope, and I have 0 clue about > >> this docker/container stuff). And also seems to have good support to > >> tie all kinds of exterrnal CI validation into pull requests (well > >> gitlab calls them merge requests, it's the same). > >> > >> One thing we're at least planning to experiment with is to take the > >> driver pull requests from drm, auto-convert them into gitlab merge > >> requests (or just ask people to directly do that), and then let to > >> bots go wild. Would give us a nice single point where you can check > >> all the information from all the different checks and vendor CI and > >> everything. Not even that much with the goal to do the merge using the > >> web ui, just to integrate all the testing and validation in one spot. > >> > >>> And the reason I mention the trivial tree is not because the trivial > >>> tree itself is all that interesting or because I'd like to belittle > >>> that model ("that will only work for trivial unimportant stuff"), but > >>> because it might be a good area to experiment in, and a way to get > >>> people used to the flow. > >>> > >>> Because if somebody is willing to every once in a while look at > >>> trivial tree pull requests and merge them to the trivial tree, maybe > >>> that person will start using the same flow for their "real" work. > >>> > >>> And I do think that "patches by email" doesn't scale. I've been there, > >>> done that, and I got the T-shirt. > >>> > >>> I used tools that some people absolutely hated to get out of that > >>> rat-hole. When that failed, I had to write my own. > >>> > >>> So I very much do think that email doesn't really work at scale. > >>> > >>> But I know the kernel people who still do real development (as opposed > >>> to me) work that way. > >>> > >>> So let me suggest a topic for the maintainer summit: > >>> "Live without email - possible?" > >>> > >>> just to get that ball rolling > >> > >> I'd say "nope", even with the s/live/patches/. Definitely not for > >> anything spanning subsystems. Even within gitlabd the cross-tree > >> support is not (yet) there. And we definitely need to have a solid > >> gitlab/mailing list gateway, which is somewhere on the huge list of > >> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o > >> is volunteer run, so all takes time. And then the gateway might be too > >> much garbage to be useful. > > > > I believe we need a common communication system that is supported by all > > subsystems. Today that system is email. > > > > If we don't want to challenge that, we'll need first-class compatibility > > between whatever new tool we introduce and email, in both direction. All > > discussions, including patch review, happening through other means (web UI > > for instance) will need to be pushed to emails, and email replies will > > need to be integrated back into the system, in such a way that will not > > completely mess up the formatting and communication flow. It has to be > > transparent enough. > > > > If we want to challenge that, we'll have to agree about another > > communication system for the whole kernel. While I don't think that's > > realistic, I'm not opposed to discussing it. However, I expect many > > developers to come up with lists of requirements, and the result of > > merging all those requirements together to be exactly email and nothing > > else :-) > > > > On my side, there are three very important features that a communication > > system should have: > > > > - It should be push-based. I don't want to have to log in and pull > > information from web UIs. > > > > - It should be customizable, offering an easy way to script review, and > > patch and pull request handling. > > > > - It should offer an offline mode. Lots of us travel a lot or generally > > have to work without an internet connection more often than we would > > like, so any solution that requires being online won't work. > > > > Emails provide all that, there may be good options I just fail to think > > about right now. > > Thanks for your list, "figuring out what we need from email to > evaluate the usefulness of the gitlab gateway" was somewhere on my > todo :-) On a serious note, if you could come up with a communication system that have all (or most) of the good features or email, without the drawbacks, I would love that. Many have tried and failed, but I hope I'll see someone succeeding in my lifetime. > More seriously: We're _really_ not far beyond the "hey, what about > gitlab" stage of this entire discussions. As mentioned, I have not > much answers, much less a plan, right now. The mail goal here is just > to figure out the right questions (and then hopefully have some useful > progress to report at LPC already). > > >> 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. > - 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. > - 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). > Aside: If you want to be involved in the nitty gritty details (aka > lots of boring fd.o admin discussions), here's the overall migration > tracking task: > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69 > > >> Whether anything of this will make it into the production drm > >> processes, no idea. "maybe" is the best answer at this time I think. > >> > >> And yes I hope that by LPC I'll have a bit more solid understanding of > >> how this gitlab thing works and what we could try out, so this isn't > >> as much high-level gossipping as it is right now :-) > > Cheers, Daniel -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:33 ` Laurent Pinchart @ 2018-09-10 22:44 ` Daniel Vetter 2018-09-11 12:44 ` Alexandre Belloni 2018-09-12 22:44 ` Laurent Pinchart 2018-09-10 22:56 ` Laurent Pinchart 1 sibling, 2 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 22:44 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit Hi Laurent, On Mon, Sep 10, 2018 at 11:33 PM, Laurent Pinchart <laurent.pinchart@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 ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 22:44 ` Daniel Vetter @ 2018-09-11 12:44 ` Alexandre Belloni 2018-09-11 14:35 ` Mark Brown 2018-09-11 15:02 ` Daniel Vetter 2018-09-12 22:44 ` Laurent Pinchart 1 sibling, 2 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-11 12:44 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit Hi, On 11/09/2018 00:44:57+0200, Daniel Vetter wrote: > 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. > I would like to chime in and remind you that there are many subsystems where you get a lot of drive-by contribution from random people. I'm obviously thinking about rtc but I think this would also apply to codec, IIO, power/supply, hwmon... In that case any initial setup would be prohibitive. I feel like these subsystems are often left to the side when I read threads like that talking about getting every patches reviewed, doing more CI, etc... So I need to emphasise that there are subsystem where people are not backed by a company to contribute or review. What I often see is someone having $random hardware and submitting a patch adding support for it. That developer will definitively not review other patches because he has no particular interest in them. He also probably doesn't have the experience to do a review. It is quite different from having a few big companies with huge teams each maintaining a single driver in a subsystem... You simply can't have the same expectations. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 12:44 ` Alexandre Belloni @ 2018-09-11 14:35 ` Mark Brown 2018-09-11 15:17 ` Alexandre Belloni 2018-09-11 15:02 ` Daniel Vetter 1 sibling, 1 reply; 162+ messages in thread From: Mark Brown @ 2018-09-11 14:35 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit [-- Attachment #1: Type: text/plain, Size: 1714 bytes --] On Tue, Sep 11, 2018 at 02:44:23PM +0200, Alexandre Belloni wrote: > On 11/09/2018 00:44:57+0200, Daniel Vetter wrote: > > 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. > I would like to chime in and remind you that there are many subsystems > where you get a lot of drive-by contribution from random people. I'm > obviously thinking about rtc but I think this would also apply to codec, > IIO, power/supply, hwmon... In that case any initial setup would be > prohibitive. Right, and this is also a potential issue for people working kernel wide if we end up with a bunch of different instances of gitlab or something similar. > So I need to emphasise that there are subsystem where people are not > backed by a company to contribute or review. What I often see is someone > having $random hardware and submitting a patch adding support for it. > That developer will definitively not review other patches because he has > no particular interest in them. He also probably doesn't have the > experience to do a review. Even where people do have corporate backing for what they're doing they've often worked pretty hard to even get the time to do submissions, or they're doing it as a byproduct of whatever the "real" goal is. It also reduces the impact from CI quite a bit if you've got lots of random drivers with most of the changes going in there, though it's still a win for the core and for any hardware which does manage to make it into a CI system. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 14:35 ` Mark Brown @ 2018-09-11 15:17 ` Alexandre Belloni 0 siblings, 0 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-11 15:17 UTC (permalink / raw) To: Mark Brown; +Cc: ksummit On 11/09/2018 15:35:38+0100, Mark Brown wrote: > On Tue, Sep 11, 2018 at 02:44:23PM +0200, Alexandre Belloni wrote: > > On 11/09/2018 00:44:57+0200, Daniel Vetter wrote: > > > > 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. > > > I would like to chime in and remind you that there are many subsystems > > where you get a lot of drive-by contribution from random people. I'm > > obviously thinking about rtc but I think this would also apply to codec, > > IIO, power/supply, hwmon... In that case any initial setup would be > > prohibitive. > > Right, and this is also a potential issue for people working kernel wide > if we end up with a bunch of different instances of gitlab or something > similar. > > > So I need to emphasise that there are subsystem where people are not > > backed by a company to contribute or review. What I often see is someone > > having $random hardware and submitting a patch adding support for it. > > That developer will definitively not review other patches because he has > > no particular interest in them. He also probably doesn't have the > > experience to do a review. > > Even where people do have corporate backing for what they're doing > they've often worked pretty hard to even get the time to do submissions, > or they're doing it as a byproduct of whatever the "real" goal is. It > also reduces the impact from CI quite a bit if you've got lots of random > drivers with most of the changes going in there, though it's still a win > for the core and for any hardware which does manage to make it into a CI > system. Yes, that is also one of my points, I often get submission form people getting the driver to work on a specific revision of the kernel (quite often a vendor tree) and it is impossible to ask them to test changes on later kernels because either they are not able to run a recent upstream kernel or they already moved on and are not interested anymore. I personally would rather not raise the bar for driver submission but that also means that I have to make untested/unreviewed changes in some of the drivers when refactoring. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 12:44 ` Alexandre Belloni 2018-09-11 14:35 ` Mark Brown @ 2018-09-11 15:02 ` Daniel Vetter 2018-09-11 22:00 ` Alexandre Belloni ` (2 more replies) 1 sibling, 3 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-11 15:02 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit On Tue, Sep 11, 2018 at 2:44 PM, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > On 11/09/2018 00:44:57+0200, Daniel Vetter wrote: >> 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. >> > > I would like to chime in and remind you that there are many subsystems > where you get a lot of drive-by contribution from random people. I'm > obviously thinking about rtc but I think this would also apply to codec, > IIO, power/supply, hwmon... In that case any initial setup would be > prohibitive. > > I feel like these subsystems are often left to the side when I read > threads like that talking about getting every patches reviewed, doing > more CI, etc... > > So I need to emphasise that there are subsystem where people are not > backed by a company to contribute or review. What I often see is someone > having $random hardware and submitting a patch adding support for it. > That developer will definitively not review other patches because he has > no particular interest in them. He also probably doesn't have the > experience to do a review. > > It is quite different from having a few big companies with huge teams > each maintaining a single driver in a subsystem... You simply can't have > the same expectations. Yes drm has drm/i915 and drm/amdgpu. But reducing the graphics folks to these two big drivers with huge teams backing them, would be about the same as stating that linux only runs on x86 and arm. There's more. And we do have quite serious problems with tiny boutique trees and drive-by contributors who immediately disappear. We're still trying to do our best to cope with that, which inolves lots of pain, and the occasional success. Here's a bunch of things we've done, all with at least one success story within drm: - Merge enough trees together until you have enough people capable to doing maintainer duties for a triumvirate. That allows you to rotate, arm-soc style. Rule of thumb is anything below 100 patches per release cycle is probably too small, but you might need a lot more than that. 3 maintainers seems to be ideal. - Intentionally abandon stuff. Sometimes no one else bothers to work because the current maintainer is all over the place, does everything, and suffocates any newbie's attempt to help out. Once something is abandoned long enough it's either known to be dead, and not worth to spend much time further maintaining. Or someone steps into the intentionally created void and helps out. - Make sure you have the smoothest ramp up from all stages of contributing. bug report, first patch, oddball patch, first reviews, then commit rights (first only for their own stuff, then maybe for others), and so on. Any slightly elevated jump will mean people walk away. - Talk about the maintainer. If no one wants to help out, but it's a generally active area, there's a problem. Fairly often it's a human problem, and the maintainer is blind to their own short-comings. This is very tricky, and requires enormous amounts of empathy and time, but can be rectified. Looking at drivers/rtc over the past 2-3 years it seems like a decently active subsystem. Probably on the small side of things, but not catastrophically so. But looking at contributor stats the picture is totally different: 241 Alexandre Belloni 28 Linus Torvalds 27 Arnd Bergmann 25 Javier Martinez Canillas 20 Uwe Kleine-König That kind of skewed contribution statistics is indeed not sustainable, and indicates some serious problem imo. What exactly goes wrong, and how to best fix it I can't tell without more information though. From my experience in drm, where we also have some areas with highly skewed contribution statistics, it could be the maintainer driving people away, ensuring that there's only one-off contributions. Usually unkowningly. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 15:02 ` Daniel Vetter @ 2018-09-11 22:00 ` Alexandre Belloni 2018-09-11 22:17 ` Guenter Roeck 2018-09-12 8:42 ` Jani Nikula 2018-09-12 9:14 ` Linus Walleij 2018-09-21 16:05 ` Joe Perches 2 siblings, 2 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-11 22:00 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit On 11/09/2018 17:02:31+0200, Daniel Vetter wrote: > On Tue, Sep 11, 2018 at 2:44 PM, Alexandre Belloni > <alexandre.belloni@bootlin.com> wrote: > > On 11/09/2018 00:44:57+0200, Daniel Vetter wrote: > >> 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. > >> > > > > I would like to chime in and remind you that there are many subsystems > > where you get a lot of drive-by contribution from random people. I'm > > obviously thinking about rtc but I think this would also apply to codec, > > IIO, power/supply, hwmon... In that case any initial setup would be > > prohibitive. > > > > I feel like these subsystems are often left to the side when I read > > threads like that talking about getting every patches reviewed, doing > > more CI, etc... > > > > So I need to emphasise that there are subsystem where people are not > > backed by a company to contribute or review. What I often see is someone > > having $random hardware and submitting a patch adding support for it. > > That developer will definitively not review other patches because he has > > no particular interest in them. He also probably doesn't have the > > experience to do a review. > > > > It is quite different from having a few big companies with huge teams > > each maintaining a single driver in a subsystem... You simply can't have > > the same expectations. > > Yes drm has drm/i915 and drm/amdgpu. But reducing the graphics folks > to these two big drivers with huge teams backing them, would be about > the same as stating that linux only runs on x86 and arm. There's more. > > And we do have quite serious problems with tiny boutique trees and > drive-by contributors who immediately disappear. We're still trying to > do our best to cope with that, which inolves lots of pain, and the > occasional success. > > Here's a bunch of things we've done, all with at least one success > story within drm: > > - Merge enough trees together until you have enough people capable to > doing maintainer duties for a triumvirate. That allows you to rotate, > arm-soc style. Rule of thumb is anything below 100 patches per release > cycle is probably too small, but you might need a lot more than that. > 3 maintainers seems to be ideal. > I'm not sure what subsystem you would want to merge... > - Intentionally abandon stuff. Sometimes no one else bothers to work > because the current maintainer is all over the place, does everything, > and suffocates any newbie's attempt to help out. Once something is > abandoned long enough it's either known to be dead, and not worth to > spend much time further maintaining. Or someone steps into the > intentionally created void and helps out. Well, that is exactly what I did, the RTC subsystem was left unmaintained until I took the maintainership. > - Make sure you have the smoothest ramp up from all stages of > contributing. bug report, first patch, oddball patch, first reviews, > then commit rights (first only for their own stuff, then maybe for > others), and so on. Any slightly elevated jump will mean people walk > away. > And that is exactly what I want you to understand. There are still many subsystem that don't spur enough interest to get people to work on it. They submit a driver, it gets merged, it works and that's it. Or maybe the subsystem is mostly complete and doesn't need more work (how hard is it to give the date and time ?) > - Talk about the maintainer. If no one wants to help out, but it's a > generally active area, there's a problem. Fairly often it's a human > problem, and the maintainer is blind to their own short-comings. This > is very tricky, and requires enormous amounts of empathy and time, but > can be rectified. > > Looking at drivers/rtc over the past 2-3 years it seems like a > decently active subsystem. Probably on the small side of things, but > not catastrophically so. But looking at contributor stats the picture > is totally different: > > 241 Alexandre Belloni > 28 Linus Torvalds > 27 Arnd Bergmann > 25 Javier Martinez Canillas > 20 Uwe Kleine-König > > That kind of skewed contribution statistics is indeed not sustainable, > and indicates some serious problem imo. What exactly goes wrong, and > how to best fix it I can't tell without more information though. From > my experience in drm, where we also have some areas with highly skewed > contribution statistics, it could be the maintainer driving people > away, ensuring that there's only one-off contributions. Usually > unkowningly. > But your conclusion is really biased to only see what you want to see. An RTC driver is simple enough to fit in a single patch and never need any fix afterwards. And again, the typical contributor will submit only one or two patches adding the driver he is interested in an move away. Unlike DRM, there is a very small chance to get back to the driver to fix issues afterwards. Anyone that got more than 1 patch in rtc already contributed a lot. I don't think there is anything to fix really, that is just the reality. The driver is submitted, it works and continues to work, I'm not sure what is wrong there. I know that I drove someone away and I'm pretty sure it should be handled better but honestly, it was a huge patch series mostly rewriting one driver without adding features. And you, probably not knowingly missed some pretty important contributions from people that added features in the rtc core but that usually adds up to 4-8 patches. Those were features that I was planning to implement so this would qualify as success stories. >From all the patches you see from me, many are cleaning up rtc drivers after a long period of time without any RTC maintainer. I also own and test most of the RTCs I'm working on. Here are the stats for the RTC core from 4.4 to 4.18: $ git shortlog --no-merges -s -n v4.4..v4.18 class.c hctosys.c interface.c nvmem.c systohc.c rtc-dev.c rtc-proc.c rtc-sysfs.c 19 Alexandre Belloni 4 Baolin Wang 3 Uwe Kleine-König 2 Joshua Clayton 2 LABBE Corentin 2 Thomas Gleixner Anyway, lets have a look at some numbers from DRM from 4.4 to 4.18: $ git shortlog --no-merges -e -s -n v4.4..v4.18 drivers/gpu/drm/drm_* 304 Daniel Vetter <daniel.vetter@ffwll.ch> 138 Ville Syrjälä <ville.syrjala@linux.intel.com> 113 Chris Wilson <chris@chris-wilson.co.uk> 94 Maarten Lankhorst <maarten.lankhorst@linux.intel.com> 44 Noralf Trønnes <noralf@tronnes.org> Ok, so the core is still dominated by you. Not as much as RTC but in the same order. Lets have a look at DRM drivers (I'm taking a subset I hope is representative): authored by reviewed by driver match others match others match on amd 5961 622 6656 318 amd.com atmel-hlcdc 18 68 3 41 maintainers etnaviv 173 72 32 55 maintainers exynos 225 173 41 80 samsung.com hisilicon 11 75 12 66 maintainers i915 6600 605 6029 831 intel.com + Chris imx 35 125 1 50 maintainers msm 380 176 31 92 maintainers + codeaurora nouveau 938 362 21 193 maintainers + nvidia.com omapdrm 278 282 56 188 ti.com stm 29 16 18 18 maintainers sun4i 154 120 53 50 maintainers tegra 134 118 11 85 nvidia.com Over the same timeframe, rtc has: rtc 228 469 0 80 maintainers This is how I interpret that: Most of the drivers are developed by their maintainer or someone paid by the vendor (which is basically the same because the maintainer is actually getting paid to get his colleagues patches upstream). I also see that the review numbers hint at biased reviews for the big drivers as they are not coming from outsiders. So what I see in DRM is exactly what you despis in other areas of the kernel: mostly unreviewed maintainer self commits. Obviously, for the smaller drivers, the numbers are not as critical because they mostly see subsystem wide changes/refactoring. So I still feel like RTC is at least as healthy as DRM because as you can see, most of the patches are not coming from a maintainer (i.e. not me). Regards, -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 22:00 ` Alexandre Belloni @ 2018-09-11 22:17 ` Guenter Roeck 2018-09-12 8:42 ` Jani Nikula 1 sibling, 0 replies; 162+ messages in thread From: Guenter Roeck @ 2018-09-11 22:17 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit On Wed, Sep 12, 2018 at 12:00:47AM +0200, Alexandre Belloni wrote: > > > > Looking at drivers/rtc over the past 2-3 years it seems like a > > decently active subsystem. Probably on the small side of things, but > > not catastrophically so. But looking at contributor stats the picture > > is totally different: > > > > 241 Alexandre Belloni > > 28 Linus Torvalds > > 27 Arnd Bergmann > > 25 Javier Martinez Canillas > > 20 Uwe Kleine-König > > > > That kind of skewed contribution statistics is indeed not sustainable, > > and indicates some serious problem imo. What exactly goes wrong, and > > how to best fix it I can't tell without more information though. From > > my experience in drm, where we also have some areas with highly skewed > > contribution statistics, it could be the maintainer driving people > > away, ensuring that there's only one-off contributions. Usually > > unkowningly. > > I have just seen this. I guess I must be driving _lots_ of people away. git shortlog --no-merges -e -s -n v4.4..v4.18 drivers/watchdog 83 Guenter Roeck <linux@roeck-us.net> 24 Wolfram Sang <wsa+renesas@sang-engineering.com> 20 Damien Riegel <damien.riegel@savoirfairelinux.com> 17 Arnd Bergmann <arnd@arndb.de> git shortlog --no-merges -e -s -n v4.4..v4.18 drivers/hwmon 157 Guenter Roeck <linux@roeck-us.net> 70 Julia Lawall <Julia.Lawall@lip6.fr> 23 Javier Martinez Canillas <javier@osg.samsung.com> 10 Linus Walleij <linus.walleij@linaro.org> 9 Pali Rohár <pali.rohar@gmail.com> And there it was me erroneously thinking that this might be related to me picking up subsystems for which there is not much interest, and to doing a lot of cleanup in those subsystems in my non-existing spare time. Bummer. Oh well, my apologies to everyone I have driven away. Guenter ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 22:00 ` Alexandre Belloni 2018-09-11 22:17 ` Guenter Roeck @ 2018-09-12 8:42 ` Jani Nikula 2018-09-12 18:45 ` Alexandre Belloni 1 sibling, 1 reply; 162+ messages in thread From: Jani Nikula @ 2018-09-12 8:42 UTC (permalink / raw) To: Alexandre Belloni, Daniel Vetter; +Cc: ksummit On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > Most of the drivers are developed by their maintainer or someone paid > by the vendor (which is basically the same because the maintainer is > actually getting paid to get his colleagues patches upstream). > > I also see that the review numbers hint at biased reviews for the big > drivers as they are not coming from outsiders. > > So what I see in DRM is exactly what you despis in other areas of the > kernel: mostly unreviewed maintainer self commits. I'll only speak for drm/i915 here as one of its maintainers, and I'll steer clear of the preceding debate, but your conclusions don't hold water wrt drm/i915. Sure, most of the contributions, both patches and review, come from paid Intel developers. It's a very busy driver. We pushed just under 8 commits per day on the average in the v4.4..v4.18 range. For reference, that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or net/ top level directories, but in the same ballpark. By our rules, *nobody* gets to push unreviewed patches, and we follow that religiously. The more complicated the patch, the more rigorous the review must be, involving domain experts or generally more sets of eyes. If we had to rely on outside reviews, either our rate of change would grind to a halt, or we'd have to loosen our rules. Instead, we trust our maintainers and committers to have the integrity to follow our documented merge criteria. And bypassing the rules would be a fast lane to losing the maintainer/committer status. Anyone contributing to drm/i915 will tell you there are no biased reviews. Some might say we are more gentle towards outside contributors than our own. I'm also pretty confident you won't find examples of unreviewed commits, let alone unreviewed maintainer self commits. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 8:42 ` Jani Nikula @ 2018-09-12 18:45 ` Alexandre Belloni 2018-09-12 19:52 ` Dave Airlie 2018-09-12 22:25 ` Daniel Vetter 0 siblings, 2 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-12 18:45 UTC (permalink / raw) To: Jani Nikula; +Cc: ksummit On 12/09/2018 11:42:53+0300, Jani Nikula wrote: > On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > Most of the drivers are developed by their maintainer or someone paid > > by the vendor (which is basically the same because the maintainer is > > actually getting paid to get his colleagues patches upstream). > > > > I also see that the review numbers hint at biased reviews for the big > > drivers as they are not coming from outsiders. > > > > So what I see in DRM is exactly what you despis in other areas of the > > kernel: mostly unreviewed maintainer self commits. > > I'll only speak for drm/i915 here as one of its maintainers, and I'll > steer clear of the preceding debate, but your conclusions don't hold > water wrt drm/i915. > > Sure, most of the contributions, both patches and review, come from paid > Intel developers. It's a very busy driver. We pushed just under 8 > commits per day on the average in the v4.4..v4.18 range. For reference, > that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or > net/ top level directories, but in the same ballpark. > > By our rules, *nobody* gets to push unreviewed patches, and we follow > that religiously. The more complicated the patch, the more rigorous the > review must be, involving domain experts or generally more sets of eyes. > I hope you do realise that we have to take your word for it because there is no way to actually verify that claim. However, I'm all for believing you. I'm just claiming that we can't actually know. > If we had to rely on outside reviews, either our rate of change would > grind to a halt, Exactly, so I guess you can understand that this is basically not something that you can ask in any other subsystem that has more than a few drivers. There is simply no way to get outside reviews on drivers. > or we'd have to loosen our rules. Instead, we trust our > maintainers and committers to have the integrity to follow our > documented merge criteria. And bypassing the rules would be a fast lane > to losing the maintainer/committer status. > > Anyone contributing to drm/i915 will tell you there are no biased > reviews. Some might say we are more gentle towards outside contributors > than our own. I'm also pretty confident you won't find examples of > unreviewed commits, let alone unreviewed maintainer self commits. > Again, this is a matter of trusting the coworkers reviews and I'm not saying that they are not happening, I'm just saying we can't know. Anyway, you are the ones maintaining your own driver and this is good, this is simply what any maintainer should do. I'm pretty convinced that you are careful to not break your own driver because that is your best interest. And it seems that you are doing a good job as it has been a while that I had issues with i915 (I wouldn't have said so two years ago). But again, I'm not sure this is the great success story Daniel claims it is. I'm just seeing a maintainer that couldn't keep up with the number of patches in his subsystem and created subsubsystems. And this is fine because the subsubsystem maintainers have huge incentives to stay around (the main one being that they are actually getting paid to do it). -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 18:45 ` Alexandre Belloni @ 2018-09-12 19:52 ` Dave Airlie 2018-09-12 22:25 ` Daniel Vetter 1 sibling, 0 replies; 162+ messages in thread From: Dave Airlie @ 2018-09-12 19:52 UTC (permalink / raw) To: alexandre.belloni; +Cc: ksummit On Thu, 13 Sep 2018 at 04:46, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 12/09/2018 11:42:53+0300, Jani Nikula wrote: > > On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > > Most of the drivers are developed by their maintainer or someone paid > > > by the vendor (which is basically the same because the maintainer is > > > actually getting paid to get his colleagues patches upstream). > > > > > > I also see that the review numbers hint at biased reviews for the big > > > drivers as they are not coming from outsiders. > > > > > > So what I see in DRM is exactly what you despis in other areas of the > > > kernel: mostly unreviewed maintainer self commits. > > > > I'll only speak for drm/i915 here as one of its maintainers, and I'll > > steer clear of the preceding debate, but your conclusions don't hold > > water wrt drm/i915. > > > > Sure, most of the contributions, both patches and review, come from paid > > Intel developers. It's a very busy driver. We pushed just under 8 > > commits per day on the average in the v4.4..v4.18 range. For reference, > > that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or > > net/ top level directories, but in the same ballpark. > > > > By our rules, *nobody* gets to push unreviewed patches, and we follow > > that religiously. The more complicated the patch, the more rigorous the > > review must be, involving domain experts or generally more sets of eyes. > > > > I hope you do realise that we have to take your word for it because > there is no way to actually verify that claim. However, I'm all for > believing you. I'm just claiming that we can't actually know. > All the i915 review is done in public on the intel-gfx mailing list, I've insisted that AMD do the same on their amd-gfx list. I also do some spot checks that nothing is sneaking past and that review is more than just rubber stamping at least where it matters. So yes you can know. Dave. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 18:45 ` Alexandre Belloni 2018-09-12 19:52 ` Dave Airlie @ 2018-09-12 22:25 ` Daniel Vetter 1 sibling, 0 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-12 22:25 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit On Wed, Sep 12, 2018 at 8:45 PM, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > On 12/09/2018 11:42:53+0300, Jani Nikula wrote: >> On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: >> > Most of the drivers are developed by their maintainer or someone paid >> > by the vendor (which is basically the same because the maintainer is >> > actually getting paid to get his colleagues patches upstream). >> > >> > I also see that the review numbers hint at biased reviews for the big >> > drivers as they are not coming from outsiders. >> > >> > So what I see in DRM is exactly what you despis in other areas of the >> > kernel: mostly unreviewed maintainer self commits. >> >> I'll only speak for drm/i915 here as one of its maintainers, and I'll >> steer clear of the preceding debate, but your conclusions don't hold >> water wrt drm/i915. >> >> Sure, most of the contributions, both patches and review, come from paid >> Intel developers. It's a very busy driver. We pushed just under 8 >> commits per day on the average in the v4.4..v4.18 range. For reference, >> that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or >> net/ top level directories, but in the same ballpark. >> >> By our rules, *nobody* gets to push unreviewed patches, and we follow >> that religiously. The more complicated the patch, the more rigorous the >> review must be, involving domain experts or generally more sets of eyes. >> > > I hope you do realise that we have to take your word for it because > there is no way to actually verify that claim. However, I'm all for > believing you. I'm just claiming that we can't actually know. > >> If we had to rely on outside reviews, either our rate of change would >> grind to a halt, > > Exactly, so I guess you can understand that this is basically not > something that you can ask in any other subsystem that has more than a > few drivers. There is simply no way to get outside reviews on drivers. I got bored, counted all the drivers in drm, it's about 100. So not quite yet where rtc is, but we're getting there. Smallest of these is just shy of 300 lines of code. Not quite as small as the smallest rtc driver I agree, but compared to drm/amdgpu a rounding error in difference really. So yeah maybe it's all fake review that we're doing, and that's why it's impossible. -Daniel >> or we'd have to loosen our rules. Instead, we trust our >> maintainers and committers to have the integrity to follow our >> documented merge criteria. And bypassing the rules would be a fast lane >> to losing the maintainer/committer status. >> >> Anyone contributing to drm/i915 will tell you there are no biased >> reviews. Some might say we are more gentle towards outside contributors >> than our own. I'm also pretty confident you won't find examples of >> unreviewed commits, let alone unreviewed maintainer self commits. >> > > Again, this is a matter of trusting the coworkers reviews and I'm not > saying that they are not happening, I'm just saying we can't know. > > Anyway, you are the ones maintaining your own driver and this is good, > this is simply what any maintainer should do. I'm pretty convinced that > you are careful to not break your own driver because that is your best > interest. And it seems that you are doing a good job as it has been a > while that I had issues with i915 (I wouldn't have said so two years > ago). > > But again, I'm not sure this is the great success story Daniel claims it > is. I'm just seeing a maintainer that couldn't keep up with the number > of patches in his subsystem and created subsubsystems. And this is fine > because the subsubsystem maintainers have huge incentives to stay around > (the main one being that they are actually getting paid to do it). > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 15:02 ` Daniel Vetter 2018-09-11 22:00 ` Alexandre Belloni @ 2018-09-12 9:14 ` Linus Walleij 2018-09-12 18:23 ` Alexandre Belloni 2018-09-21 16:05 ` Joe Perches 2 siblings, 1 reply; 162+ messages in thread From: Linus Walleij @ 2018-09-12 9:14 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit-discuss On Tue, Sep 11, 2018 at 5:02 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > - Merge enough trees together until you have enough people capable to > doing maintainer duties for a triumvirate. That allows you to rotate, > arm-soc style. Rule of thumb is anything below 100 patches per release > cycle is probably too small, but you might need a lot more than that. > 3 maintainers seems to be ideal. This is the kind of rules of thumb we need to scale development IMO. "My" subsystems (GPIO and pinctrl) is on some hard to define threshold. I keep at it for now. Maybe I should just merge them into one single tree to deliberately get a big enough mass to get some group maintainership going. > - Intentionally abandon stuff. Sometimes no one else bothers to work > because the current maintainer is all over the place, does everything, > and suffocates any newbie's attempt to help out. (...) > That kind of skewed contribution statistics is indeed not sustainable, > and indicates some serious problem imo. What exactly goes wrong, and > how to best fix it I can't tell without more information though. From > my experience in drm, where we also have some areas with highly skewed > contribution statistics, it could be the maintainer driving people > away, ensuring that there's only one-off contributions. Usually > unkowningly. This problem is likely psychological and/or sociologial or even ethnological rather than technical. Despite several attempts of kernel maintainers to actively downplay their role (Torvalds sets a good example in Documentation/process/management-style.rst) kernel maintainers are still perceived from the outside as some kind of superior beings to which layperson developers feel inferior to and look up to. I think it's not an option to try to stop people from looking up to kernel maintainers no matter how much we'd like that, instead we need to assume the responsibility. I do not know how to best deal with this, I guess maintainers really need to watch their behaviors, but we would better ask someone experienced in group dynamics what desirable behaviors are. If I take a guess I suspect the same qualities are desired for any good leader or good parent: maintainers should have infinite patience, infinite time to reply to questions (also infinitisemal latency so they are always there!), recognize all their own weaknesses and always say they are sorry when they have been rude, be encouraging, sweet, nurturing, criticize in a way that makes it clear that it is the performance not the person that needs improvement, and throwing in some extra rewards for desired behavior every now and then. (I think someone mentioned a pareto ratio of 80% praise and 20% critique is ideal, it's likely an unscientific rule of thumb.) Needless to say no real person lives up to the above. No parent does either. Some just fail less or in less obvious ways. I am worried that the intersection of the sets of people that naturally have the desired personality traits and also are reasonably good engineers is actually pretty small and that is why we have a problem. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 9:14 ` Linus Walleij @ 2018-09-12 18:23 ` Alexandre Belloni 2018-09-12 18:44 ` Thomas Gleixner 2018-09-12 21:21 ` Linus Walleij 0 siblings, 2 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-12 18:23 UTC (permalink / raw) To: Linus Walleij; +Cc: ksummit-discuss On 12/09/2018 11:14:14+0200, Linus Walleij wrote: > On Tue, Sep 11, 2018 at 5:02 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > That kind of skewed contribution statistics is indeed not sustainable, > > and indicates some serious problem imo. What exactly goes wrong, and > > how to best fix it I can't tell without more information though. From > > my experience in drm, where we also have some areas with highly skewed > > contribution statistics, it could be the maintainer driving people > > away, ensuring that there's only one-off contributions. Usually > > unkowningly. > > This problem is likely psychological and/or sociologial or even > ethnological rather than technical. > > Despite several attempts of kernel maintainers to actively downplay > their role (Torvalds sets a good example in > Documentation/process/management-style.rst) > kernel maintainers are still perceived from the outside as some > kind of superior beings to which layperson developers feel > inferior to and look up to. > > I think it's not an option to try to stop people from looking > up to kernel maintainers no matter how much we'd like that, > instead we need to assume the responsibility. > > I do not know how to best deal with this, I guess maintainers > really need to watch their behaviors, but we would better ask > someone experienced in group dynamics what desirable > behaviors are. > > If I take a guess I suspect the same qualities are desired for any > good leader or good parent: maintainers should have infinite > patience, infinite time to reply to questions (also infinitisemal > latency so they are always there!), recognize all their own > weaknesses and always say they are sorry when they have > been rude, be encouraging, sweet, nurturing, criticize in a > way that makes it clear that it is the performance not the person > that needs improvement, and throwing in some extra rewards > for desired behavior every now and then. (I think someone > mentioned a pareto ratio of 80% praise and 20% critique > is ideal, it's likely an unscientific rule of thumb.) > > Needless to say no real person lives up to the above. > No parent does either. Some just fail less or in less obvious > ways. > > I am worried that the intersection of the sets of people that > naturally have the desired personality traits and also are > reasonably good engineers is actually pretty small and that is > why we have a problem. > But is there really a problem to begin with? This is what Daniel wants everybody to believe. He didn't scale in his own subsystem and basically gave up reviewing drivers and this seems to be working fine for DRM. But trying to impose that supposedly "new maintainership model" (again, the numbers would indicate it is as hierarchical as any other part of the kernel) to all the maintainers is quite far fetched. Many maintainers are keeping up with their load and patches are getting reviewed and applied. I'm not saying there aren't any issues and that the level of reviews is sufficient but I really don't think problematic maintainers are as widespread as Daniel claims. It is really getting tiring to see him show random statistics and draw wrong conclusions from them. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 18:23 ` Alexandre Belloni @ 2018-09-12 18:44 ` Thomas Gleixner 2018-09-13 12:08 ` Maxime Ripard 2018-09-12 21:21 ` Linus Walleij 1 sibling, 1 reply; 162+ messages in thread From: Thomas Gleixner @ 2018-09-12 18:44 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit-discuss On Wed, 12 Sep 2018, Alexandre Belloni wrote: > On 12/09/2018 11:14:14+0200, Linus Walleij wrote: > I'm not saying there aren't any issues and that the level of reviews is > sufficient but I really don't think problematic maintainers are as > widespread as Daniel claims. It is really getting tiring to see him > show random statistics and draw wrong conclusions from them. Agreed. Lies, damned lies and statistics... The really interesting metric would be bugs/nr_commits. That gives you valuable information how good your subsystem works and interacts with the rest of the kernel. But even then you need to be careful about analyzing the nature of the bugs, which range between sloppy and incredibly unfortunate because subtle interaction with changes outside of that maintainer tree brought the carefully worked out patch into broken state. Thanks, tglx ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 18:44 ` Thomas Gleixner @ 2018-09-13 12:08 ` Maxime Ripard 2018-09-13 12:57 ` Alexandre Belloni 2018-09-14 7:08 ` Linus Walleij 0 siblings, 2 replies; 162+ messages in thread From: Maxime Ripard @ 2018-09-13 12:08 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 2481 bytes --] On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote: > On Wed, 12 Sep 2018, Alexandre Belloni wrote: > > On 12/09/2018 11:14:14+0200, Linus Walleij wrote: > > I'm not saying there aren't any issues and that the level of reviews is > > sufficient but I really don't think problematic maintainers are as > > widespread as Daniel claims. It is really getting tiring to see him > > show random statistics and draw wrong conclusions from them. > > Agreed. Lies, damned lies and statistics... > > The really interesting metric would be bugs/nr_commits. That gives you > valuable information how good your subsystem works and interacts with the > rest of the kernel. That's one angle to look at it, and I agree it would be a pretty good overview of how good a maintainer is at reviewing patches, in general. However, there's different angles where the metric used by Daniel makes sense. If there's a very significant part of the work that is done by the maintainer of a given subsystem, and that there is a single maintainer for that subsystem, what will happen when that maintainer decides to stop contributing for some reason? All the knowledge they built, experience they got (including at reviewing) is gone, possibly forever, and there's no one to pick up the subsystem, and the code is left to rot. Maintainers burn-out are also a thing, that is only reinforced by being the sole one caring for that subsystem. And then, you also have the issue that nothing prevents that maintainer to enforce particuliar rules and thus prevent contributors, reinforcing the fact that they would be the sole maintainer for that subsystem. As a community, we should care about those issues as well. Basically, the whole Linus discussion should apply at all the levels of the hierarchy, for pretty much the same reasons. Having multiple maintainers and / or a more even spread of the contributions mitigate all these. So Daniel's metric is a pretty good one, and it doesn't mean that a particular maintainer is bad at their job, or is not making any effort, or shouldn't be praised. It really is a different metric, for a different issue. It's like running a datacenter off a single machine, with a single power supply, a single internet connection and a single hard disk. No one would want that. "But the bandwidth is good". Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 12:08 ` Maxime Ripard @ 2018-09-13 12:57 ` Alexandre Belloni 2018-09-13 13:18 ` Maxime Ripard 2018-09-13 14:25 ` Jani Nikula 2018-09-14 7:08 ` Linus Walleij 1 sibling, 2 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-13 12:57 UTC (permalink / raw) To: Maxime Ripard; +Cc: ksummit-discuss On 13/09/2018 14:08:11+0200, Maxime Ripard wrote: > On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote: > > On Wed, 12 Sep 2018, Alexandre Belloni wrote: > > > On 12/09/2018 11:14:14+0200, Linus Walleij wrote: > > > I'm not saying there aren't any issues and that the level of reviews is > > > sufficient but I really don't think problematic maintainers are as > > > widespread as Daniel claims. It is really getting tiring to see him > > > show random statistics and draw wrong conclusions from them. > > > > Agreed. Lies, damned lies and statistics... > > > > The really interesting metric would be bugs/nr_commits. That gives you > > valuable information how good your subsystem works and interacts with the > > rest of the kernel. > > That's one angle to look at it, and I agree it would be a pretty good > overview of how good a maintainer is at reviewing patches, in general. > > However, there's different angles where the metric used by Daniel > makes sense. If there's a very significant part of the work that is > done by the maintainer of a given subsystem, and that there is a > single maintainer for that subsystem, what will happen when that > maintainer decides to stop contributing for some reason? > Daniel's metric (at least the one he used to gauge RTC) will never ever be the good one. He simply looked at my contributions versus the top contributors. The reality is that I'm taking more contributor patches than I write. If you have a look at the DRM statistics I gave, the situation is actually quite similar. Contribution for each driver is massively dominated by its maintainer. For the big ones (i915, amd, exynos), if the company decides to stop developing the driver, it will be completely dead. For the small one they basically only have one real contributor. > All the knowledge they built, experience they got (including at > reviewing) is gone, possibly forever, and there's no one to pick up > the subsystem, and the code is left to rot. > And this is almost the same for the DRM core where Daniel is by far the top contributor. > Maintainers burn-out are also a thing, that is only reinforced by > being the sole one caring for that subsystem. > > And then, you also have the issue that nothing prevents that > maintainer to enforce particuliar rules and thus prevent contributors, > reinforcing the fact that they would be the sole maintainer for that > subsystem. > This is a real issue. What I'm saying is that it is not that common. > As a community, we should care about those issues as well. Basically, > the whole Linus discussion should apply at all the levels of the > hierarchy, for pretty much the same reasons. > > Having multiple maintainers and / or a more even spread of the > contributions mitigate all these. So Daniel's metric is a pretty good > one, and it doesn't mean that a particular maintainer is bad at their > job, or is not making any effort, or shouldn't be praised. It really > is a different metric, for a different issue. > It is a very biased metric that will show in a bad light any subsystem that has a small core and many drivers. Conversely, it will show that unmaintained subsystems where all the patches are going through akpm are working well. > It's like running a datacenter off a single machine, with a single > power supply, a single internet connection and a single hard disk. No > one would want that. > Group maintainership is definitively good but you can't force people to get interested in a subsystem. and this is almost never an issue with the maintainer attitude that would be driving off contributors. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 12:57 ` Alexandre Belloni @ 2018-09-13 13:18 ` Maxime Ripard 2018-09-13 14:25 ` Jani Nikula 1 sibling, 0 replies; 162+ messages in thread From: Maxime Ripard @ 2018-09-13 13:18 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 5411 bytes --] On Thu, Sep 13, 2018 at 02:57:23PM +0200, Alexandre Belloni wrote: > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote: > > On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote: > > > On Wed, 12 Sep 2018, Alexandre Belloni wrote: > > > > On 12/09/2018 11:14:14+0200, Linus Walleij wrote: > > > > I'm not saying there aren't any issues and that the level of reviews is > > > > sufficient but I really don't think problematic maintainers are as > > > > widespread as Daniel claims. It is really getting tiring to see him > > > > show random statistics and draw wrong conclusions from them. > > > > > > Agreed. Lies, damned lies and statistics... > > > > > > The really interesting metric would be bugs/nr_commits. That gives you > > > valuable information how good your subsystem works and interacts with the > > > rest of the kernel. > > > > That's one angle to look at it, and I agree it would be a pretty good > > overview of how good a maintainer is at reviewing patches, in general. > > > > However, there's different angles where the metric used by Daniel > > makes sense. If there's a very significant part of the work that is > > done by the maintainer of a given subsystem, and that there is a > > single maintainer for that subsystem, what will happen when that > > maintainer decides to stop contributing for some reason? > > > > Daniel's metric (at least the one he used to gauge RTC) will never ever > be the good one. He simply looked at my contributions versus the top > contributors. The reality is that I'm taking more contributor patches > than I write. > > If you have a look at the DRM statistics I gave, the situation is > actually quite similar. Contribution for each driver is massively > dominated by its maintainer. For the big ones (i915, amd, exynos), if > the company decides to stop developing the driver, it will be > completely dead. For the small one they basically only have one real > contributor. > > > All the knowledge they built, experience they got (including at > > reviewing) is gone, possibly forever, and there's no one to pick up > > the subsystem, and the code is left to rot. > > > > And this is almost the same for the DRM core where Daniel is by far the > top contributor. DRM is far from perfect. No one ever said it was, and I disagree on some of the solutions that were implemented there. However, having imperfect solutions doesn't make the underlying problem go away. > > Maintainers burn-out are also a thing, that is only reinforced by > > being the sole one caring for that subsystem. > > > > And then, you also have the issue that nothing prevents that > > maintainer to enforce particuliar rules and thus prevent contributors, > > reinforcing the fact that they would be the sole maintainer for that > > subsystem. > > This is a real issue. What I'm saying is that it is not that common. Yet you have first-hand experience with at least two of them. And it's *one* symptom of the same upstream issue. The fact that you can't have a quite holiday without drowning in mails when you go back, or that you can't take a break from the kernel for whatever reason without putting the code you maintained and cared for for so long is another one. > > As a community, we should care about those issues as well. Basically, > > the whole Linus discussion should apply at all the levels of the > > hierarchy, for pretty much the same reasons. > > > > Having multiple maintainers and / or a more even spread of the > > contributions mitigate all these. So Daniel's metric is a pretty good > > one, and it doesn't mean that a particular maintainer is bad at their > > job, or is not making any effort, or shouldn't be praised. It really > > is a different metric, for a different issue. > > It is a very biased metric that will show in a bad light any subsystem > that has a small core and many drivers. Can we stop about the "bad light"? Back to the datacenter example, pointing out that there's a single hard disk doesn't show a bad light on the one that is there. It just points out that we should prepare for the worse and add redundancy *before* the worse happens. > Conversely, it will show that unmaintained subsystems where all the > patches are going through akpm are working well. Just like Thomas' metric will show that subsystems where a single patch changing a printk or adding a comment would be the ideal subsystem. This is just as good as any metric, and should be looked at with some distance. > > It's like running a datacenter off a single machine, with a single > > power supply, a single internet connection and a single hard disk. No > > one would want that. > > Group maintainership is definitively good but you can't force people to > get interested in a subsystem. and this is almost never an issue with > the maintainer attitude that would be driving off contributors. Again, you have a handful of first-hand experiences. And true, you can't force people to be interested in a subsystem. And implementing group maintainership will be hard for some subsystems with a particular contribution pattern, just like yours. But can't we at least acknowledge the issue and tend to fixing it when we can? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 12:57 ` Alexandre Belloni 2018-09-13 13:18 ` Maxime Ripard @ 2018-09-13 14:25 ` Jani Nikula 2018-09-13 20:05 ` Thomas Gleixner 1 sibling, 1 reply; 162+ messages in thread From: Jani Nikula @ 2018-09-13 14:25 UTC (permalink / raw) To: Alexandre Belloni, Maxime Ripard; +Cc: ksummit-discuss On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote: >> All the knowledge they built, experience they got (including at >> reviewing) is gone, possibly forever, and there's no one to pick up >> the subsystem, and the code is left to rot. > > And this is almost the same for the DRM core where Daniel is by far the > top contributor. Except he's no longer a maintainer in either DRM or i915. Checking the stats against current MAINTAINERS will paint you a different picture. And that brings us to another important point: Group maintainership allows for easier onboarding of new maintainers, and easier retirement of old ones. We've changed several maintainers for both the drm-misc tree and i915 since we've switched to group maintainership, and there hasn't been noticeable bumps in the road. Mostly just business as usual. Being a maintainer doesn't have to be for life, and you don't have to burn out and rage quit one fine day and leave everything in ruins behind you as you go. I'm not saying one size fits all, and I'm not saying it's easy to find more maintainers. But it's certainly much *much* easier to find a new co-maintainer to a team of two or three than a new solo maintainer. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 14:25 ` Jani Nikula @ 2018-09-13 20:05 ` Thomas Gleixner 2018-09-13 23:02 ` Rodrigo Vivi 2018-09-14 6:39 ` Dave Airlie 0 siblings, 2 replies; 162+ messages in thread From: Thomas Gleixner @ 2018-09-13 20:05 UTC (permalink / raw) To: Jani Nikula; +Cc: ksummit-discuss On Thu, 13 Sep 2018, Jani Nikula wrote: > On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote: > >> All the knowledge they built, experience they got (including at > >> reviewing) is gone, possibly forever, and there's no one to pick up > >> the subsystem, and the code is left to rot. > > > > And this is almost the same for the DRM core where Daniel is by far the > > top contributor. > > Except he's no longer a maintainer in either DRM or i915. Checking the > stats against current MAINTAINERS will paint you a different picture. > > And that brings us to another important point: Group maintainership > allows for easier onboarding of new maintainers, and easier retirement > of old ones. We've changed several maintainers for both the drm-misc > tree and i915 since we've switched to group maintainership, and there > hasn't been noticeable bumps in the road. Mostly just business as > usual. Being a maintainer doesn't have to be for life, and you don't > have to burn out and rage quit one fine day and leave everything in > ruins behind you as you go. > > I'm not saying one size fits all, and I'm not saying it's easy to find > more maintainers. But it's certainly much *much* easier to find a new > co-maintainer to a team of two or three than a new solo maintainer. You are sounding like DRM invented group maintainership and needs to go advertising it now as the best invention since sliced bread. It's been in practice since 2007 when the tip tree started with 3 maintainers. It was then adopted by ARM-SoC and Linus recommended it as a good model way before DRM went that road. We all know that group maintainership is a good thing, but we also know that it's not working for all subsystems and that it's not always easy to find matching co-maintainers. Most maintainers, if not all, would be happy to have a competent, trusted and interested co-maintainer. So it's not that they need to be educated on that. Group maintainership is not the Panacea. So please stop the prayer wheel and come up with solutions which address identifed indivudual problems. Not having group maintainership is for some subsystems the least of their worries. And as a member of the first official maintainer group in the kernel I can assure you that group maintainership is not making all other and potentially more dangerous problems magically go away. Thanks, tglx ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 20:05 ` Thomas Gleixner @ 2018-09-13 23:02 ` Rodrigo Vivi 2018-09-14 6:47 ` Rafael J. Wysocki 2018-09-14 6:39 ` Dave Airlie 1 sibling, 1 reply; 162+ messages in thread From: Rodrigo Vivi @ 2018-09-13 23:02 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 3569 bytes --] On Thu, Sep 13, 2018 at 1:07 PM Thomas Gleixner <tglx@linutronix.de> wrote: > On Thu, 13 Sep 2018, Jani Nikula wrote: > > On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> > wrote: > > > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote: > > >> All the knowledge they built, experience they got (including at > > >> reviewing) is gone, possibly forever, and there's no one to pick up > > >> the subsystem, and the code is left to rot. > > > > > > And this is almost the same for the DRM core where Daniel is by far the > > > top contributor. > > > > Except he's no longer a maintainer in either DRM or i915. Checking the > > stats against current MAINTAINERS will paint you a different picture. > > > > And that brings us to another important point: Group maintainership > > allows for easier onboarding of new maintainers, and easier retirement > > of old ones. We've changed several maintainers for both the drm-misc > > tree and i915 since we've switched to group maintainership, and there > > hasn't been noticeable bumps in the road. Mostly just business as > > usual. Being a maintainer doesn't have to be for life, and you don't > > have to burn out and rage quit one fine day and leave everything in > > ruins behind you as you go. > > > > I'm not saying one size fits all, and I'm not saying it's easy to find > > more maintainers. But it's certainly much *much* easier to find a new > > co-maintainer to a team of two or three than a new solo maintainer. > > You are sounding like DRM invented group maintainership and needs to go > advertising it now as the best invention since sliced bread. > I had to read the thread twice to see if I could understand how you arrived to this conclusion. I really didn't see anyone claiming to be the inventor of group maintainership. And this is really not the point of what Daniel is proposing here. > It's been in practice since 2007 when the tip tree started with 3 > maintainers. It was then adopted by ARM-SoC and Linus recommended it as a > good model way before DRM went that road. > Good for you! Well, it actually might be good for everyone if you have lessons learned for sharing as Daniel proposed: "- New experiments in group maintainership, and sharing lessons learned in general." > > We all know that group maintainership is a good thing, but we also know > that it's not working for all subsystems and that it's not always easy to > find matching co-maintainers. Most maintainers, if not all, would be happy > to have a competent, trusted and interested co-maintainer. So it's not that > they need to be educated on that. > What I see on Daniel's email is not an education proposal, but to just talk and share experience. He is "open to anything else really on the larger topic of community mangement." > > Group maintainership is not the Panacea. So please stop the prayer wheel > and come up with solutions which address identifed indivudual problems. Not > having group maintainership is for some subsystems the least of their > worries. And as a member of the first official maintainer group in the > kernel I can assure you that group maintainership is not making all other > and potentially more dangerous problems magically go away. > But if there's time to discuss I don't know why they should be exclusive things... Thanks, Rodrigo. > Thanks, > > tglx > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > [-- Attachment #2: Type: text/html, Size: 5257 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 23:02 ` Rodrigo Vivi @ 2018-09-14 6:47 ` Rafael J. Wysocki 0 siblings, 0 replies; 162+ messages in thread From: Rafael J. Wysocki @ 2018-09-14 6:47 UTC (permalink / raw) To: Rodrigo Vivi; +Cc: ksummit-discuss On Friday, September 14, 2018 1:02:57 AM CEST Rodrigo Vivi wrote: > On Thu, Sep 13, 2018 at 1:07 PM Thomas Gleixner <tglx@linutronix.de> wrote: > [cut] > > > > > Group maintainership is not the Panacea. So please stop the prayer wheel > > and come up with solutions which address identifed indivudual problems. Not > > having group maintainership is for some subsystems the least of their > > worries. And as a member of the first official maintainer group in the > > kernel I can assure you that group maintainership is not making all other > > and potentially more dangerous problems magically go away. > > > > But if there's time to discuss I don't know why they should be exclusive > things... It's very much like saying "This works for me, so it also has to work for you or if it doesn't, explain that to me, please!" However, the real case is that different things work for different people and by doing the above you really make people feel like they need to defend themselves, which isn't particularly friendly to be honest. And if you want any positive changes to happen, making people feel like they need to defend themselves is really counter-productive. While it is tempting to try to impose specific similar (or even identical) solutions on everybody, which often happens in politics mind you, that often goes against techical merit, personal preferences or sometimes even against what it achievable in practice given the available resources and time. Of course, you totally have the right to advocate for certain things, but then please realize that your experience may not be the same as the experience of the others and respect that. Thanks, Rafael ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 20:05 ` Thomas Gleixner 2018-09-13 23:02 ` Rodrigo Vivi @ 2018-09-14 6:39 ` Dave Airlie 2018-09-14 14:15 ` Thomas Gleixner 1 sibling, 1 reply; 162+ messages in thread From: Dave Airlie @ 2018-09-14 6:39 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit > You are sounding like DRM invented group maintainership and needs to go > advertising it now as the best invention since sliced bread. > > It's been in practice since 2007 when the tip tree started with 3 > maintainers. It was then adopted by ARM-SoC and Linus recommended it as a > good model way before DRM went that road. How many new maintainers at the x86 group brought in, how many maintainers has it removed? What processes have you developed for this? Just having 3 people do something once isn't really helping the other groups figure out a plan. The drm group maintainer ship is a lot more mature than others as in there has been both joins and departs from the 2-3 groups that use the tools and system. > We all know that group maintainership is a good thing, but we also know > that it's not working for all subsystems and that it's not always easy to > find matching co-maintainers. Most maintainers, if not all, would be happy > to have a competent, trusted and interested co-maintainer. So it's not that > they need to be educated on that. > > Group maintainership is not the Panacea. So please stop the prayer wheel > and come up with solutions which address identifed indivudual problems. Not > having group maintainership is for some subsystems the least of their > worries. And as a member of the first official maintainer group in the > kernel I can assure you that group maintainership is not making all other > and potentially more dangerous problems magically go away. > We have a lot more time than one slot. I think other subsystems might want some ideas on how to move to group maintainership, and copy "TIP" or "arm-soc" isn't helpful for them. I've just migrated all the drm-next and fixes trees to the same tools as the two group maintainer trees, it now means for the first time in 10 years I can actually give someone else full access to the exact same system as I use for sending trees to Linus, and more importantly we can have people learn the system on the misc or i915 trees and grow into toplevel maintainers, with ease. I think it's valuable discussion to move from "you didn't invent this, we've been doing it since 1956 on mainframes, to how can we make this into a process that works for other subsystem maintainers). Dave. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-14 6:39 ` Dave Airlie @ 2018-09-14 14:15 ` Thomas Gleixner 2018-09-17 7:40 ` Daniel Vetter 0 siblings, 1 reply; 162+ messages in thread From: Thomas Gleixner @ 2018-09-14 14:15 UTC (permalink / raw) To: Dave Airlie; +Cc: ksummit On Fri, 14 Sep 2018, Dave Airlie wrote: > I think it's valuable discussion to move from "you didn't invent this, > we've been doing it since 1956 on mainframes, to how can we make this > into a process that works for other subsystem maintainers). It would be also valuable to sit back and think about - why the DRM model works well for DRM - why it is not necessarily applicable for other subsystems - why other maintainer groups have different setups and issues instead of telling everyone it works great for DRM, everyone should do that and then pull random statistics to tell people that they have a problem. I'm all for exchanging ideas and information, but I'm totally not interested in the condescending tone which tells the world that anyone not doing the DRM thing has a problem. DRM is fundamentally different than anything I maintain. The vast majority of contributors and therefore potential maintainers are working in corporate teams, which are there to care about DRM and the corporates graphics cards. On my end, the only larger group of constant contributors is around perf tooling as there seems to be a vested interest of distros to make this work. We have a well working setup there. The kernel side looks fundamentally different. We surely have maintainers where we could gain them. We have a few regular reviewers, but that's it. Everything else is drive by, random corporate feature enablement thrown over the fence, distro value add etc. Nothing where you can keep people affiliated. We do not have the concept of teams dedicated to the problem space. We can't split it into bits and pieces as it's intervowen at the hardware level to quite some extent. Aside of that there are neither teams nor individuals who care about one particular piece more than they care about the whole thing. I'm well aware of these problems, I talk openly about them, and try to come up with solutions since years, but I can't change the way corporates work and people tick at all. I lost at least two submaintainers after they gained speed just because they changed jobs and vanished into nirwana. I'm not buying at all, that having standardized setups and tools and whatever, will change any of the underlying issues magically. It won't make contributors more careful, it won't make developers magically take over responsibility, it won't change the corporate 'get this feature thrown over the fence' mentality, it won't make people appear who deeply care. It's nice that it works so well for you and I wish it would work in other places similarly well, but please can we take that step back and look at the specific problems of a specific subsystem instead of telling everyone that they have a problem and offering the DRM way as Panacea. Unless that systematic and specific analysis happens, I'm out of this discussion. Thanks, tglx ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-14 14:15 ` Thomas Gleixner @ 2018-09-17 7:40 ` Daniel Vetter 0 siblings, 0 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-17 7:40 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit Comment on timing: I typed this up on Friday, but wanted to sit on it for a bit more and do some editing. Then w/e happened, and I guess this now looks somewhat strange since it doesn't take latest development into account. Since I'm still processing these I figured I'll just send this out as-is. On Fri, Sep 14, 2018 at 4:15 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Fri, 14 Sep 2018, Dave Airlie wrote: >> I think it's valuable discussion to move from "you didn't invent this, >> we've been doing it since 1956 on mainframes, to how can we make this >> into a process that works for other subsystem maintainers). > > It would be also valuable to sit back and think about > > - why the DRM model works well for DRM > > - why it is not necessarily applicable for other subsystems > > - why other maintainer groups have different setups and issues > > instead of telling everyone it works great for DRM, everyone should do that > and then pull random statistics to tell people that they have a problem. > > I'm all for exchanging ideas and information, but I'm totally not > interested in the condescending tone which tells the world that anyone not > doing the DRM thing has a problem. > > DRM is fundamentally different than anything I maintain. The vast majority > of contributors and therefore potential maintainers are working in > corporate teams, which are there to care about DRM and the corporates > graphics cards. > > On my end, the only larger group of constant contributors is around perf > tooling as there seems to be a vested interest of distros to make this > work. We have a well working setup there. > > The kernel side looks fundamentally different. We surely have maintainers > where we could gain them. We have a few regular reviewers, but that's it. DRM is more than just drm/i915 and drm/amdgpu. Yes those are indeed fairly unusual cases, and when I made the conferences rounds presenting about our committer model 2 years back I highlight that it probably works much better if you have a tight-nit team. Both i915 and amdgpu work with a committer model (amdgpu's unfortunately not quite as aggressively public, there's still maintainers cherry-picking staged patches over to the final trees). But we also have a tons of drivers which range from outright drive-thru to just chronically under-maintained reverse-engineered stacks. Some have some coporate backing, a lot of it along the lines of "I need to get this feature in, where can I drop my patches". So 2-3 years ago I'd say we definitely had a lot of the problems you and other maintainers in this thread are describing. We still have a lot of these, but I think we've substantial improved upon our own old status quo. And yes, drm ex. i915&amdgpu is a bit smaller than tip, but a fairly substantial junk still. > Everything else is drive by, random corporate feature enablement thrown > over the fence, distro value add etc. Nothing where you can keep people > affiliated. > > We do not have the concept of teams dedicated to the problem space. We > can't split it into bits and pieces as it's intervowen at the hardware > level to quite some extent. Aside of that there are neither teams nor > individuals who care about one particular piece more than they care about > the whole thing. > > I'm well aware of these problems, I talk openly about them, and try to come > up with solutions since years, but I can't change the way corporates work > and people tick at all. I lost at least two submaintainers after they > gained speed just because they changed jobs and vanished into nirwana. These are all the same problems we've had (and to some extent, still have) in small drm drivers, not mostly maintained as part of drm-misc. > I'm not buying at all, that having standardized setups and tools and > whatever, will change any of the underlying issues magically. Standard tooling is indeed fairly miniscule thing (and we're definitely not even close to an optimum with the drm tooling we do have). But it contributes. Creating a great community where people want to hang around in, even if it's not the job they're directly paid for, takes a lot of work, at all fronts. No single item is going to be your magic fix, but in aggregate, you really need all the pieces (or most of them at least). > It won't make contributors more careful, it won't make developers magically > take over responsibility, it won't change the corporate 'get this feature > thrown over the fence' mentality, it won't make people appear who deeply > care. > > It's nice that it works so well for you and I wish it would work in other > places similarly well, but please can we take that step back and look at > the specific problems of a specific subsystem instead of telling everyone > that they have a problem and offering the DRM way as Panacea. > > Unless that systematic and specific analysis happens, I'm out of this > discussion. I think most of the specific things we've learned in drm have been brought up in the discussion already. Individually they indeed don't seem all that important, so let me summarize them here: - commit rights also works with a very lousely coupled group of people. In drm-misc we've stuffed random tiny drivers all over the place into one tree, and it's not utter chaos. This is new, since 2 years ago I mentioned that we've only tried this on tight-nit vendor teams. - stuffing even somewhat unrelated things into one tree, and encouraging collaboration through the stick of forced cross-review, helps a lot in improving the bus factor. Even for tiny things you end up with more than 1 person who occasionally looked at it and has some clue. Again, this is a newly gained insight. - the pipeline from drive-thru contributor, to occasional, then regular, then experienced enough to provide useful review, and so on, until they start taking over maintainer duties is very lossy, and generally takes a few years. It's also extremely sensitive to even the tiniest barriers and hurdles - whether you end up with a new maintainer or not feels like a "death by a thousand papercuts" thing. And generally the people who drop out never tell you why, so figuring out what hurts requires tons of experimenting. So even tiny things that look totally inconsequential at first sight matter hugely for the overall success here. Like tooling. - it's paramount that people feel their contributions are valued - they have tons of reasons for walking away asap, and the only thing we can give them in return for staying is a warm and fuzzy feeling. Which pays like shit, but it's all we have. We try to aggressively recognize good contributors by giving them commit rights, adding them formally as reviewers to MAINTAINERS, bunch of thank yous (I'm really bad at those myself and do way too little). You'd probably be in complete shock how quickly we hand out these charges and responsibilities, but in the large scheme it really does work. - we crack down hard on anything that might drive away contributors. There's two big pieces here, first our Code of Conduct. Yes we enforce it, and yes I have the mails to prove that people notice, and that they stick around because we manage to create a more respectful and constructive atmosphere. The other is that there's no special priviledges for maintainers. If you have special maintainer powers, you make it pretty clear that everyone else is a 2nd class contributor, and no amount of recognizing is going to fix that and make people stay when they have other duties that keep them busy. And yes, DRM is by far not perfect. We still have a bunch of trees and drivers which aren't well maintained in my opinion. And we're trying out new things to figure out whether we can improve on the status quo. What's flat out not true on the other hand is that we're just doing a bunch of philosophical waxing, that we don't have similar problems to everyone else (just a different mix of them of course), and that we haven't figured out new stuff the past 2 years and new lessons learned. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-13 12:08 ` Maxime Ripard 2018-09-13 12:57 ` Alexandre Belloni @ 2018-09-14 7:08 ` Linus Walleij 2018-09-14 7:39 ` Geert Uytterhoeven 1 sibling, 1 reply; 162+ messages in thread From: Linus Walleij @ 2018-09-14 7:08 UTC (permalink / raw) To: Maxime Ripard; +Cc: ksummit-discuss On Thu, Sep 13, 2018 at 2:08 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > If there's a very significant part of the work that is > done by the maintainer of a given subsystem, and that there is a > single maintainer for that subsystem, what will happen when that > maintainer decides to stop contributing for some reason? > > All the knowledge they built, experience they got (including at > reviewing) is gone, possibly forever, and there's no one to pick up > the subsystem, and the code is left to rot. Unfortunately this is what happened when David Brownell passed away. His passing had a long-standing and serious impact on the quality of the subsystems he helped creating. GPIO was left unmaintained and patches were coming in and merged by Andrew Morton, as is default (and it is a good thing that we don't just stop merging code, that would probably have been even worse). Most of it was fine. However one piece that got merged at this turbulent time was the GPIO sysfs ABI which in my opinion was not very nice. The main problem was that it exposed kernel internals (the global GPIO numberspace) to the whole world and made them semi-ABI which is really tricky to maintain in the long run. It probably didn't seem like a big problem at the time and GPIO was seen as obscure. But it has created a major maintenance headache, and I imagine that an active maintainer would have come up with something a bit different. I have moved that ABI to "obsolete" and try to make the new character device ABI as tasty as possible to encourage migration but it will have to be maintained until there is noone left in the forest to hear the tree fall when I cut it. I guess in 2045 or so. There are other things that was David's ideas, such as highly optimized bit-banging routines in SPI where it would have been great to have his input. Those are less severe, but I can't help to compare with the MMC/SD subsystem where at one point last year I could reach out to the previous-to-previous maintainer (Pierre Ossman) and ask why the subsystem had a bounce buffer mechanism, which was really helpful because he quickly provided the answer and we managed to fix it up nicely (commit bd9b902798ab). Yours, Linus Walleij ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-14 7:08 ` Linus Walleij @ 2018-09-14 7:39 ` Geert Uytterhoeven 2018-09-14 8:08 ` Linus Walleij 0 siblings, 1 reply; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-14 7:39 UTC (permalink / raw) To: Linus Walleij; +Cc: ksummit-discuss Hi Linus, On Fri, Sep 14, 2018 at 9:08 AM Linus Walleij <linus.walleij@linaro.org> wrote: > On Thu, Sep 13, 2018 at 2:08 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > If there's a very significant part of the work that is > > done by the maintainer of a given subsystem, and that there is a > > single maintainer for that subsystem, what will happen when that > > maintainer decides to stop contributing for some reason? > > > > All the knowledge they built, experience they got (including at > > reviewing) is gone, possibly forever, and there's no one to pick up > > the subsystem, and the code is left to rot. > > Unfortunately this is what happened when David Brownell > passed away. His passing had a long-standing and serious > impact on the quality of the subsystems he helped creating. > > GPIO was left unmaintained and patches were coming in > and merged by Andrew Morton, as is default (and it is a > good thing that we don't just stop merging code, that would > probably have been even worse). Most of it was fine. > > However one piece that got merged at this turbulent time > was the GPIO sysfs ABI which in my opinion > was not very nice. The main problem was that it exposed > kernel internals (the global GPIO numberspace) to the whole > world and made them semi-ABI which is really tricky to > maintain in the long run. It probably didn't seem like a big > problem at the time and GPIO was seen as obscure. But > it has created a major maintenance headache, and I imagine > that an active maintainer would have come up with something > a bit different. While we do miss David Brownell, I think there are some errors in your timeline. Commit d8f388d8dc8d4f36 ("gpio: sysfs interface") was authored by David himself. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-14 7:39 ` Geert Uytterhoeven @ 2018-09-14 8:08 ` Linus Walleij 0 siblings, 0 replies; 162+ messages in thread From: Linus Walleij @ 2018-09-14 8:08 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: ksummit-discuss On Fri, Sep 14, 2018 at 9:39 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Fri, Sep 14, 2018 at 9:08 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > However one piece that got merged at this turbulent time > > was the GPIO sysfs ABI which in my opinion > > was not very nice. The main problem was that it exposed > > kernel internals (the global GPIO numberspace) to the whole > > world and made them semi-ABI which is really tricky to > > maintain in the long run. It probably didn't seem like a big > > problem at the time and GPIO was seen as obscure. But > > it has created a major maintenance headache, and I imagine > > that an active maintainer would have come up with something > > a bit different. > > While we do miss David Brownell, I think there are some errors in your > timeline. Commit d8f388d8dc8d4f36 ("gpio: sysfs interface") was authored > by David himself. Sigh yeah git history never lies, things were wrong in my head ... :/ It would nevertheless have been nice to have him around to explain how this was thought out. Possibly I would have been told off and discouraged to remove the sysfs ABI at all. IIRC I asked some of the other people of this commit at one point what the ideas was, and the answer was "we just needed something to control GPIOs from userspace". Yours, Linus Walleij ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-12 18:23 ` Alexandre Belloni 2018-09-12 18:44 ` Thomas Gleixner @ 2018-09-12 21:21 ` Linus Walleij 1 sibling, 0 replies; 162+ messages in thread From: Linus Walleij @ 2018-09-12 21:21 UTC (permalink / raw) To: Alexandre Belloni; +Cc: ksummit-discuss On Wed, Sep 12, 2018 at 8:23 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > [Me] > > I am worried that the intersection of the sets of people that > > naturally have the desired personality traits and also are > > reasonably good engineers is actually pretty small and that is > > why we have a problem. > > But is there really a problem to begin with? This is what Daniel wants > everybody to believe. He didn't scale in his own subsystem and basically > gave up reviewing drivers and this seems to be working fine for DRM. To me the problem is recruiting active maintainers, and not the formal title and the entry in MAINTAINERS, but one that actually feels responsibility for the code. Some have appeared in the past, they make some really nice contributions and then move on. But it is a bit like solar flares, I just don't know when they will turn up next and what makes them passionate and stay or when they leave. The upside (IMO) of DRMs model is that more people feel resonsible for the code. The downside is the risk that no-one does, and everyone just thinks someone else will do stuff. They seem to land on the plus so far. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-11 15:02 ` Daniel Vetter 2018-09-11 22:00 ` Alexandre Belloni 2018-09-12 9:14 ` Linus Walleij @ 2018-09-21 16:05 ` Joe Perches 2 siblings, 0 replies; 162+ messages in thread From: Joe Perches @ 2018-09-21 16:05 UTC (permalink / raw) To: Daniel Vetter, Alexandre Belloni; +Cc: ksummit On Tue, 2018-09-11 at 17:02 +0200, Daniel Vetter wrote: > - Talk about the maintainer. If no one wants to help out, but it's a > generally active area, there's a problem. Fairly often it's a human > problem, and the maintainer is blind to their own short-comings. This > is very tricky, and requires enormous amounts of empathy and time, but > can be rectified. Somewhat dubious assertion. Perhaps more often it is a generally active but somewhat isolated subsystem that few take an interest in. > Looking at drivers/rtc over the past 2-3 years it seems like a > decently active subsystem. Probably on the small side of things, but > not catastrophically so. But looking at contributor stats the picture > is totally different: > > 241 Alexandre Belloni > 28 Linus Torvalds > 27 Arnd Bergmann > 25 Javier Martinez Canillas > 20 Uwe Kleine-König > > That kind of skewed contribution statistics is indeed not sustainable, > and indicates some serious problem imo. It's not necessarily serious. A single active maintainer is well capable of maintaining a subsystem as long as it's somewhat contained. It is curious though that one of the nominal maintainers, Alessandro Zummo, has not signed any single commit since 2015 though. > What exactly goes wrong, and > how to best fix it I can't tell without more information though. From > my experience in drm, where we also have some areas with highly skewed > contribution statistics, it could be the maintainer driving people > away, ensuring that there's only one-off contributions. Usually > unkowningly. Possible, but one-off contributions skew noisily today to trivial whitespace and checkpatch/clang warning updates. It generally requires an advanced knowledge of a subsystem to be able to make substantive or even non-trivial changes. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 22:44 ` Daniel Vetter 2018-09-11 12:44 ` Alexandre Belloni @ 2018-09-12 22:44 ` Laurent Pinchart 1 sibling, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-12 22:44 UTC (permalink / raw) To: Daniel Vetter; +Cc: ksummit Hi Daniel, On Tuesday, 11 September 2018 01:44:57 EEST Daniel Vetter wrote: > 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. I understand you point, and I'll claim you could do all this using patchwork too :-) Of course the amount of development would very well be prohibitive, and I'm not advocating for that. On a more serious note, maybe our disagreement comes (partly) from not having defined which feature(s) of gitlab you would like to use. The CI infrastructure, as in taking a branch, running tests on it, reporting results, and offering a web dashboard (as long as it remains optional), seems totally fine with me. Pushing to branches with particular names/paths instead of issuing a pull request by e-mail, if it helps the CI system figuring out what to test and when, is something I wouldn't oppose either (provided the push would send a mail to appropriate mailing lists to notify everybody of pull requests, possibly formatted the same way as a git request-pull). Regardless of how our tool is named, I'd like it to offer e-mail integration - In the incoming direction (as patchwork does), as there will always be patches submitted by e-mail. Compared to commits pushed to a git tree, patch series submitted by e-mail may make it more difficult to extract some context information (heuristics would likely be needed to track multiple versions of the same series for instance), and some information might not be available at all, so we might not be able to offer the same level of integration in that case, but we should do as much as we can. We may also try to standardize the formatting of information in patches or cover letters to ease the task for our tools (for instance a standard way to tell which branch a patch series is based on could be useful). I however don't want to make it more difficult than it is already to submit patches by e-mail. - In the outgoing direction, as operations directly performed through git (e.g. pull requests, and possibly merges, as a reply to the pull request e- mail) should be reflected on mailing list to inform all developers, and to retain history. Given how much information many developers have to filter, require information to be pulled from a web interface will simply not work, it has to be pushed through a mean that will ensure that the audience is reached. > >> - 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. I've replied to my own comment separately, I believe we're in agreement here. > >> - 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. Replacing a git send-email with a git push wouldn't be an issue for me as long as we address the requirements listed above. What would be an absolute no-go for me would be patch (and pull requests) review over a web interface. > 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. How far do we want to go to make obnoxious and clueless IT departments happy ? What about corporate environments where a proxy server intercepts even https traffic, with custom certificates installed on all machines, which is unfortunately not that uncommon ? I personally wouldn't trust such an environment, so we have to set a firm limit somewhere in any case. > 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. Yes, manual intervention will sometimes be needed, and regardless of the tool we use that will require a bit of work on the submitter's side, but I think that's doable. > 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. Let's not forget that gitlab instances, like git trees, won't be there forever, they will likely come and go. We should link information in a way that will survive that. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:33 ` Laurent Pinchart 2018-09-10 22:44 ` Daniel Vetter @ 2018-09-10 22:56 ` Laurent Pinchart 1 sibling, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 22:56 UTC (permalink / raw) To: ksummit-discuss On Tuesday, 11 September 2018 00:33:36 EEST 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: > >>> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote: > >>>> On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote: > >>>>> - Assuming it gets accepted I think my LPC talk on "migrating to > >>>>> gitlab" will raise some questions, and probably overflow into hallway > >>>>> track or a BOF session. > >>> > >>> First a bit more context: This is a different talk than the other > >>> "stuff drm people are doing" talks I've done in the past: We haven't > >>> done anything yet. We haven't even really started planning the > >>> migration yet :-) > >>> > >>> The idea here was that for once I don't do a talk when it's all done, > >>> but way ahead of that when we're still figuring things out. The > >>> underlying reason for the migration is that fd.o admins want to shut > >>> down their home-grown collage of services and replace it with > >>> something that's much easier to maintain, provides solid 2FA and > >>> allows them to offload a lot of the admin work (handing out access > >>> rights and stuff) to all the projects their hosting. Plus stop the > >>> shell access services, if that's ever possible. > >>> > >>> So right now this is only about moving the git server from one place > >>> to the other. And we haven't even done the full plan for that > >>> migration (it's a pile of repos and stuff). So really very early. But > >>> now that we do have this modern thing, a lot of people are looking > >>> into all the shiny features it offers, and trying to figure out > >>> whether they're useful for us or not. And that's what I want to go > >>> through in the talk - the title is a bit on the clickbait side :-) > >>> > >>>> I've not used gitlab personally, but I *have* used github for a much > >>>> smaller project. > >>>> > >>>> I have to say, the random and relaxed model is enjoyable. I can see > >>>> how somebody coming from that, then finds the strict kernel rules (and > >>>> _different_ rules for different parts) off-putting and confusing. > >>>> > >>>> At the same time, I have to say that people need to keep in mind that > >>>> the kernel is *different*. We're not a small project with five > >>>> developers that isn't all that critical. Some of our off-putting > >>>> development models are there for a very very good reason. I think a > >>>> lot of people who find the kernel unfriendly just don't appreciate > >>>> that part. > >>>> > >>>> The kernel used to be pretty free-wheeling too. 20+ years ago. > >>> > >>> What I definitely don't want is a free-wheeling thing a la your > >>> standard github repo. There's also the issue that github massively > >>> optimizes for small projects in their entire setup. I've done a blog > >>> post about that a while ago and chatted with a bunch of githubbers, > >>> they're really not interested in big-project workflows that much. > >>> > >>> gitlab otoh is very interested in that, and they picked up some of the > >>> concepts around how we use topic branches and pull requests in the > >>> kernel. It's by far not all implemented yet, but a lot more promising > >>> than anything else I've looked at. And we can always just keep using > >>> our existing tooling ofc. > >>> > >>> Aside from this there's a bunch of other reasons fd.o admins picked > >>> gitlab (against other contenders they checked out), but this is one of > >>> the big ones. At least from the kernel's pov. For anyone bored enough, > >>> here's the full details of the why from fd.o admins: > >>> > >>> https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > >>> > >>>> And I still hate how github ends up making it really really easy to > >>>> make horribly bad commit messages, and it encourages a "just rebase on > >>>> top of the integration branch" model, and I do not believe that it > >>>> would ever work for the kernel at large. Too much room for chaos. > >>>> > >>>> BUT. > >>>> > >>>> I do think it's still instructive to look at how those "fun small > >>>> projects" work. Having the whole web interface and a more relaxed > >>>> setup is a good thing. And it's probably *better* than the strict > >>>> rules when you don't really need those strict rules. > >>>> > >>>> So I do believe that it could work for a subsystem. Because "too much > >>>> room for chaos" ends up being nice when you don't want to worry about > >>>> the proper channels etc. > >>>> > >>>> For example, we've had the "trivial tree", which tends to be a really > >>>> thankless project, that might well be managed way more easily by just > >>>> having a random tree that lots of people can commit to, and we could > >>>> even encourage the github (gitlab?) model of random non-kernel people > >>>> just sending their random trees to it, and have then the group of > >>>> committers be able to merge the changes (and at least on github, the > >>>> default merge is just a fast-forward, so it actually acts more like a > >>>> patch queue than a git tree). > >>> > >>> Yeah, the trivial/"fun first contributions" process is a lot more > >>> polished on many of these projects, and there's a bunch such things we > >>> kinda want to look into longer-term. And this really is all long-term, > >>> because just the initial git server migration most likely won't even > >>> start until next year. > >>> > >>> A much bigger thing for us is CI integration. patchwork + patch bombs > >>> + lots of tears and gin do kinda work, but it's super painful and a > >>> real chaos no one has any overview over. gitlab has really neat > >>> integrated CI for anything that you can run on containers/virtual > >>> machines (already played with it, pretty dope, and I have 0 clue about > >>> this docker/container stuff). And also seems to have good support to > >>> tie all kinds of exterrnal CI validation into pull requests (well > >>> gitlab calls them merge requests, it's the same). > >>> > >>> One thing we're at least planning to experiment with is to take the > >>> driver pull requests from drm, auto-convert them into gitlab merge > >>> requests (or just ask people to directly do that), and then let to > >>> bots go wild. Would give us a nice single point where you can check > >>> all the information from all the different checks and vendor CI and > >>> everything. Not even that much with the goal to do the merge using the > >>> web ui, just to integrate all the testing and validation in one spot. > >>> > >>>> And the reason I mention the trivial tree is not because the trivial > >>>> tree itself is all that interesting or because I'd like to belittle > >>>> that model ("that will only work for trivial unimportant stuff"), but > >>>> because it might be a good area to experiment in, and a way to get > >>>> people used to the flow. > >>>> > >>>> Because if somebody is willing to every once in a while look at > >>>> trivial tree pull requests and merge them to the trivial tree, maybe > >>>> that person will start using the same flow for their "real" work. > >>>> > >>>> And I do think that "patches by email" doesn't scale. I've been there, > >>>> done that, and I got the T-shirt. > >>>> > >>>> I used tools that some people absolutely hated to get out of that > >>>> rat-hole. When that failed, I had to write my own. > >>>> > >>>> So I very much do think that email doesn't really work at scale. > >>>> > >>>> But I know the kernel people who still do real development (as opposed > >>>> to me) work that way. > >>>> > >>>> So let me suggest a topic for the maintainer summit: > >>>> "Live without email - possible?" > >>>> > >>>> just to get that ball rolling > >>> > >>> I'd say "nope", even with the s/live/patches/. Definitely not for > >>> anything spanning subsystems. Even within gitlabd the cross-tree > >>> support is not (yet) there. And we definitely need to have a solid > >>> gitlab/mailing list gateway, which is somewhere on the huge list of > >>> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o > >>> is volunteer run, so all takes time. And then the gateway might be too > >>> much garbage to be useful. > >> > >> I believe we need a common communication system that is supported by all > >> subsystems. Today that system is email. > >> > >> If we don't want to challenge that, we'll need first-class compatibility > >> between whatever new tool we introduce and email, in both direction. All > >> discussions, including patch review, happening through other means (web > >> UI for instance) will need to be pushed to emails, and email replies will > >> need to be integrated back into the system, in such a way that will not > >> completely mess up the formatting and communication flow. It has to be > >> transparent enough. > >> > >> If we want to challenge that, we'll have to agree about another > >> communication system for the whole kernel. While I don't think that's > >> realistic, I'm not opposed to discussing it. However, I expect many > >> developers to come up with lists of requirements, and the result of > >> merging all those requirements together to be exactly email and nothing > >> else :-) > >> > >> On my side, there are three very important features that a communication > >> system should have: > >> > >> - It should be push-based. I don't want to have to log in and pull > >> information from web UIs. > >> > >> - It should be customizable, offering an easy way to script review, and > >> patch and pull request handling. > >> > >> - It should offer an offline mode. Lots of us travel a lot or generally > >> have to work without an internet connection more often than we would > >> like, so any solution that requires being online won't work. > >> > >> Emails provide all that, there may be good options I just fail to think > >> about right now. > > > > Thanks for your list, "figuring out what we need from email to > > evaluate the usefulness of the gitlab gateway" was somewhere on my > > todo :-) > > On a serious note, if you could come up with a communication system that > have all (or most) of the good features or email, without the drawbacks, I > would love that. Many have tried and failed, but I hope I'll see someone > succeeding in my lifetime. > > > More seriously: We're _really_ not far beyond the "hey, what about > > gitlab" stage of this entire discussions. As mentioned, I have not > > much answers, much less a plan, right now. The mail goal here is just > > to figure out the right questions (and then hopefully have some useful > > progress to report at LPC already). > > > >>> 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. > > > - 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. After a private discussion I realize I've chosen my words unwisely. Newcomers and regular contributors are not antagonists, as "both sides" could be interpreted to mean. I really meant "everybody" here, as we have a continuum of profiles in our developers community. We should strive for making everybody happy. My point is that, with the large number of developers and the wide diversity of profiles, that goal will never be fully reached as the processes we put in place can only be the result of a compromise. I thus wanted to emphasize that we shouldn't rule e-mail out on the basis that it's not ideal, or possibly painful, for some groups of profiles, the same way we should not consider a particular process as immutable on the basis that other groups of profiles got so used to it that they now suffer from Stockholm syndrome. Care needs to be taken to minimize the pain points for everybody alike. > > - 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). > > > Aside: If you want to be involved in the nitty gritty details (aka > > lots of boring fd.o admin discussions), here's the overall migration > > tracking task: > > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69 > > > >>> Whether anything of this will make it into the production drm > >>> processes, no idea. "maybe" is the best answer at this time I think. > >>> > >>> And yes I hope that by LPC I'll have a bit more solid understanding of > >>> how this gitlab thing works and what we could try out, so this isn't > >>> as much high-level gossipping as it is right now :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 20:32 ` Laurent Pinchart 2018-09-10 20:55 ` Daniel Vetter @ 2018-09-10 21:11 ` Theodore Y. Ts'o 2018-09-10 23:05 ` Laurent Pinchart 2018-09-10 21:19 ` Konstantin Ryabitsev 2 siblings, 1 reply; 162+ messages in thread From: Theodore Y. Ts'o @ 2018-09-10 21:11 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit-discuss On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > On my side, there are three very important features that a communication > system should have: > > - It should be push-based. I don't want to have to log in and pull information > from web UIs. > > - It should be customizable, offering an easy way to script review, and patch > and pull request handling. > > - It should offer an offline mode. Lots of us travel a lot or generally have > to work without an internet connection more often than we would like, so any > solution that requires being online won't work. > > Emails provide all that, there may be good options I just fail to think about > right now. One more requirement I would add is that messages should be archived, and should have a first class search system. We should be able to reference a commit id in a communications thread, and then a search for that commit id (or commit description) should be able to turn up that message, and from there, be able to see the rest of the messages on that thread. Being able to find the "legislative history" behind a particular change in the kernel is super-important. - Ted ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:11 ` Theodore Y. Ts'o @ 2018-09-10 23:05 ` Laurent Pinchart 2018-09-17 11:43 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 162+ messages in thread From: Laurent Pinchart @ 2018-09-10 23:05 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: ksummit-discuss Hi Ted, On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote: > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > > On my side, there are three very important features that a communication > > system should have: > > > > - It should be push-based. I don't want to have to log in and pull > > information from web UIs. > > > > - It should be customizable, offering an easy way to script review, and > > patch and pull request handling. > > > > - It should offer an offline mode. Lots of us travel a lot or generally > > have to work without an internet connection more often than we would > > like, so any solution that requires being online won't work. > > > > Emails provide all that, there may be good options I just fail to think > > about right now. > > One more requirement I would add is that messages should be archived, > and should have a first class search system. We should be able to > reference a commit id in a communications thread, and then a search > for that commit id (or commit description) should be able to turn up > that message, and from there, be able to see the rest of the messages > on that thread. > > Being able to find the "legislative history" behind a particular > change in the kernel is super-important. Fully agreed. I would even go one step further, I'd like a system where relationships between messages are kept. This obviously means linking patches from the same series, but also detecting new versions of patch series (to the extent possible, as already discussed in this mail thread). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 23:05 ` Laurent Pinchart @ 2018-09-17 11:43 ` Mauro Carvalho Chehab 2018-09-17 12:03 ` Geert Uytterhoeven 2018-09-17 13:12 ` Christoph Hellwig 0 siblings, 2 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 11:43 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit-discuss Em Tue, 11 Sep 2018 02:05:06 +0300 Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > Hi Ted, > > On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote: > > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > > > On my side, there are three very important features that a communication > > > system should have: > > > > > > - It should be push-based. I don't want to have to log in and pull > > > information from web UIs. > > > > > > - It should be customizable, offering an easy way to script review, and > > > patch and pull request handling. > > > > > > - It should offer an offline mode. Lots of us travel a lot or generally > > > have to work without an internet connection more often than we would > > > like, so any solution that requires being online won't work. > > > > > > Emails provide all that, there may be good options I just fail to think > > > about right now. > > > > One more requirement I would add is that messages should be archived, > > and should have a first class search system. We should be able to > > reference a commit id in a communications thread, and then a search > > for that commit id (or commit description) should be able to turn up > > that message, and from there, be able to see the rest of the messages > > on that thread. > > > > Being able to find the "legislative history" behind a particular > > change in the kernel is super-important. > > Fully agreed. I would even go one step further, I'd like a system where > relationships between messages are kept. This obviously means linking patches > from the same series, but also detecting new versions of patch series (to the > extent possible, as already discussed in this mail thread). > Let me go one step down. While I do agree that the main Kernel development should happen via email on the foreseen future, Why e-mail would be a mandatory requirement for all kinds of Kernel development? I don't believe that a single development model fits all cases. Let's say that someone is using something like github to manage the development of a single driver - or even a low traffic subsystem. The communication traffic between the developers there is usually not relevant (nor wanted) at LKML. What we usually do on normal subsystems is to have those discussions "filtered" on a separate mailing list. I don't see why not use a web-based interface for such purpose. Btw, that's not that different on what happens on some companies that do their driver developments internally. They do whatever they want when developing the driver. Only when they have something ready they use e-mail. A github-like interface is actually better than that, as people interested on such driver/subsystem could contribute earlier than on a closed doors model, as the discussions can be seen publicly. On both cases, the only relevant discussions for LKML and for the Kernel maintainer that would be taking their patches are when they send a pull request upstream. Granted, there will be some drawbacks if email interface is not available if such development community would need to talk with other subsystems. So, yes, it is desirable to have an e-mail interface, as otherwise a human would have to handle such things manually, but, again, for low traffic development, such things would be doable. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 11:43 ` Mauro Carvalho Chehab @ 2018-09-17 12:03 ` Geert Uytterhoeven 2018-09-17 13:04 ` Mauro Carvalho Chehab 2018-09-17 13:12 ` Christoph Hellwig 1 sibling, 1 reply; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-17 12:03 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss Hi Mauro, On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > Em Tue, 11 Sep 2018 02:05:06 +0300 > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > > On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote: > > > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > > > > On my side, there are three very important features that a communication > > > > system should have: > > > > > > > > - It should be push-based. I don't want to have to log in and pull > > > > information from web UIs. > > > > > > > > - It should be customizable, offering an easy way to script review, and > > > > patch and pull request handling. > > > > > > > > - It should offer an offline mode. Lots of us travel a lot or generally > > > > have to work without an internet connection more often than we would > > > > like, so any solution that requires being online won't work. > > > > > > > > Emails provide all that, there may be good options I just fail to think > > > > about right now. > > > > > > One more requirement I would add is that messages should be archived, > > > and should have a first class search system. We should be able to > > > reference a commit id in a communications thread, and then a search > > > for that commit id (or commit description) should be able to turn up > > > that message, and from there, be able to see the rest of the messages > > > on that thread. > > > > > > Being able to find the "legislative history" behind a particular > > > change in the kernel is super-important. > > > > Fully agreed. I would even go one step further, I'd like a system where > > relationships between messages are kept. This obviously means linking patches > > from the same series, but also detecting new versions of patch series (to the > > extent possible, as already discussed in this mail thread). > > > > Let me go one step down. > > While I do agree that the main Kernel development should happen via > email on the foreseen future, Why e-mail would be a mandatory > requirement for all kinds of Kernel development? > > I don't believe that a single development model fits all cases. > > Let's say that someone is using something like github to manage the > development of a single driver - or even a low traffic subsystem. > > The communication traffic between the developers there is usually > not relevant (nor wanted) at LKML. > > What we usually do on normal subsystems is to have those discussions > "filtered" on a separate mailing list. I don't see why not use a > web-based interface for such purpose. > > Btw, that's not that different on what happens on some companies that > do their driver developments internally. They do whatever they want > when developing the driver. Only when they have something ready they > use e-mail. > > A github-like interface is actually better than that, as people > interested on such driver/subsystem could contribute earlier than > on a closed doors model, as the discussions can be seen publicly. > > On both cases, the only relevant discussions for LKML and for the > Kernel maintainer that would be taking their patches are when they > send a pull request upstream. Development doesn't stop when the driver has been developed and merged in mainline. It's a good idea to always CC lkml when submitting a patch for a bug in the driver. > Granted, there will be some drawbacks if email interface is not > available if such development community would need to talk with > other subsystems. So, yes, it is desirable to have an e-mail > interface, as otherwise a human would have to handle such things > manually, but, again, for low traffic development, such things > would be doable. And once the driver has been integrated, maintenance (changed subsystem APIs, cleanups, ...) will need be done, on a larger scale. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 12:03 ` Geert Uytterhoeven @ 2018-09-17 13:04 ` Mauro Carvalho Chehab 2018-09-17 13:10 ` Julia Lawall 2018-09-17 14:14 ` Laurent Pinchart 0 siblings, 2 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 13:04 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: ksummit-discuss Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven <geert@linux-m68k.org> escreveu: > Hi Mauro, > > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab > <mchehab+samsung@kernel.org> wrote: > > Em Tue, 11 Sep 2018 02:05:06 +0300 > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > > > On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote: > > > > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > > > > > On my side, there are three very important features that a communication > > > > > system should have: > > > > > > > > > > - It should be push-based. I don't want to have to log in and pull > > > > > information from web UIs. > > > > > > > > > > - It should be customizable, offering an easy way to script review, and > > > > > patch and pull request handling. > > > > > > > > > > - It should offer an offline mode. Lots of us travel a lot or generally > > > > > have to work without an internet connection more often than we would > > > > > like, so any solution that requires being online won't work. > > > > > > > > > > Emails provide all that, there may be good options I just fail to think > > > > > about right now. > > > > > > > > One more requirement I would add is that messages should be archived, > > > > and should have a first class search system. We should be able to > > > > reference a commit id in a communications thread, and then a search > > > > for that commit id (or commit description) should be able to turn up > > > > that message, and from there, be able to see the rest of the messages > > > > on that thread. > > > > > > > > Being able to find the "legislative history" behind a particular > > > > change in the kernel is super-important. > > > > > > Fully agreed. I would even go one step further, I'd like a system where > > > relationships between messages are kept. This obviously means linking patches > > > from the same series, but also detecting new versions of patch series (to the > > > extent possible, as already discussed in this mail thread). > > > > > > > Let me go one step down. > > > > While I do agree that the main Kernel development should happen via > > email on the foreseen future, Why e-mail would be a mandatory > > requirement for all kinds of Kernel development? > > > > I don't believe that a single development model fits all cases. > > > > Let's say that someone is using something like github to manage the > > development of a single driver - or even a low traffic subsystem. > > > > The communication traffic between the developers there is usually > > not relevant (nor wanted) at LKML. > > > > What we usually do on normal subsystems is to have those discussions > > "filtered" on a separate mailing list. I don't see why not use a > > web-based interface for such purpose. > > > > Btw, that's not that different on what happens on some companies that > > do their driver developments internally. They do whatever they want > > when developing the driver. Only when they have something ready they > > use e-mail. > > > > A github-like interface is actually better than that, as people > > interested on such driver/subsystem could contribute earlier than > > on a closed doors model, as the discussions can be seen publicly. > > > > On both cases, the only relevant discussions for LKML and for the > > Kernel maintainer that would be taking their patches are when they > > send a pull request upstream. > > Development doesn't stop when the driver has been developed and merged > in mainline. Yeah, sure. > It's a good idea to always CC lkml when submitting a patch for a bug in the > driver. True, but this doesn't always happen. If it happens, nothing prevents that someone would use a "man-handled copy-and-paste interface" between e-mail and web. Btw, this happens already, even with e-mail: from time to time, we receive bug reports on media from something reported via distro bug tracks (bugzilla, Trac, ...). Even when the bug tracking system has an email interface (Red Hat BZ has, for example), it is really rare to use email for tracked bug reports (even from Kernel.org bugzilla). What works in practice for such bugs is that we end by using web interfaces if we need to talk about the bug inside the tracker system, or via e-mail if we want to talk about it subsystem-wide. Sub-optimal, but it works. The same would happen if the development discussions would happen inside a web interface like github/gitlab. Of course, the maintainer would still need to be reachable by e-mail. > > Granted, there will be some drawbacks if email interface is not > > available if such development community would need to talk with > > other subsystems. So, yes, it is desirable to have an e-mail > > interface, as otherwise a human would have to handle such things > > manually, but, again, for low traffic development, such things > > would be doable. > > And once the driver has been integrated, maintenance (changed > subsystem APIs, cleanups, ...) will need be done, on a larger scale. True, but still doable. See, I don't have myself any plans to use something like github for Kernel development. Yet, I think we should be open to work with people that would prefer to work with such model. Btw, on a quick look, it seems that github has/had an email interface already: https://blog.github.com/2011-03-10-reply-to-comments-from-email/ It seems that there are ways to create new issues there via e-mail too, although currently it sounds a little hacky (requiring either to run an script or to add a github bot user to the project): https://stackoverflow.com/questions/25051686/create-github-issue-from-freshdesk Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:04 ` Mauro Carvalho Chehab @ 2018-09-17 13:10 ` Julia Lawall 2018-09-17 13:29 ` Christoph Hellwig 2018-09-17 14:14 ` Laurent Pinchart 1 sibling, 1 reply; 162+ messages in thread From: Julia Lawall @ 2018-09-17 13:10 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss > Btw, on a quick look, it seems that github has/had an email > interface already: > https://blog.github.com/2011-03-10-reply-to-comments-from-email/ I only interact with issues posted to github via email (alpine specifically). The only problem is that people tend to omit context, because they assume that you see the code or previous messages that they see in the web interface, which you do not. julia ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:10 ` Julia Lawall @ 2018-09-17 13:29 ` Christoph Hellwig 2018-09-17 13:48 ` Laurent Pinchart 2018-09-17 13:58 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 162+ messages in thread From: Christoph Hellwig @ 2018-09-17 13:29 UTC (permalink / raw) To: Julia Lawall; +Cc: Mauro Carvalho Chehab, ksummit-discuss On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote: > > Btw, on a quick look, it seems that github has/had an email > > interface already: > > https://blog.github.com/2011-03-10-reply-to-comments-from-email/ > > I only interact with issues posted to github via email (alpine > specifically). The only problem is that people tend to omit context, > because they assume that you see the code or previous messages that they > see in the web interface, which you do not. The major problem with github is that as far as I can tell there is no way to interact with it without creating an account. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:29 ` Christoph Hellwig @ 2018-09-17 13:48 ` Laurent Pinchart 2018-09-17 13:58 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-17 13:48 UTC (permalink / raw) To: ksummit-discuss; +Cc: Christoph Hellwig, Mauro Carvalho Chehab On Monday, 17 September 2018 16:29:08 EEST Christoph Hellwig wrote: > On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote: > > > Btw, on a quick look, it seems that github has/had an email > > > > > > interface already: > > > https://blog.github.com/2011-03-10-reply-to-comments-from-email/ > > > > I only interact with issues posted to github via email (alpine > > specifically). The only problem is that people tend to omit context, > > because they assume that you see the code or previous messages that they > > see in the web interface, which you do not. > > The major problem with github is that as far as I can tell there is no > way to interact with it without creating an account. That's what bothers me as well. I'm not opposed to a subsystem replacing git request-pull + email with git-push, provided that an e-mail gateway forwards the pull request to the appropriate mailing lists. I'm also no opposed to a subsystem offering git-push as an optional alternative to git-send-email to submit patches, provided the above e-mail gateway. What I don't want is having to create accounts and authenticate the git-push, as that would make drive-by contributions more difficult. For the replacement of pull requests I could live with having to submit my ssh public key (but not individually to all subsystems), but for the alternative to patch submission by e-mail we would need to support unauthenticated git-push. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:29 ` Christoph Hellwig 2018-09-17 13:48 ` Laurent Pinchart @ 2018-09-17 13:58 ` Mauro Carvalho Chehab 2018-09-17 14:18 ` Christoph Hellwig ` (2 more replies) 1 sibling, 3 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 13:58 UTC (permalink / raw) To: Christoph Hellwig; +Cc: ksummit-discuss Em Mon, 17 Sep 2018 06:29:08 -0700 Christoph Hellwig <hch@infradead.org> escreveu: > On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote: > > > Btw, on a quick look, it seems that github has/had an email > > > interface already: > > > https://blog.github.com/2011-03-10-reply-to-comments-from-email/ > > > > I only interact with issues posted to github via email (alpine > > specifically). The only problem is that people tend to omit context, > > because they assume that you see the code or previous messages that they > > see in the web interface, which you do not. > > The major problem with github is that as far as I can tell there is no > way to interact with it without creating an account. Well, the same happens with moderated mailing lists. There are a lot of them: $ git grep moderated MAINTAINERS|wc -l 221 Except when it is something that I really want to be merged (e. g. something that affects my own machines or I have a demand from my employer), when a perfectly fine patch I sent is ignored by such lists, I just ignore whatever e-mail I receive from their mailman interface, and I assume that, if I don't receive any reply from a human, either the maintainers of such subsystem(s) accepted it or they just don't care enough. So, if it is patch affecting media, I just apply after a reasonable reviewing time. In the case of github-like interfaces, I would do the same: I would copy the maintainer(s) and just ignore any "non-subscriber's warning" kind of e-mail. That's actually one difference in this case: while on moderated ML you need to be added to each individual ML in order to send e-mails, on a web-based interface, just one subscription is enough for all projects hosted there, and there are a lot less git hosting servers than email mailing lists. So, in the specific case of github, I wouldn't have any issues, as I had to create an account there due to other purposes. Yet, I don't have any need right now to have an account on gitlab or Pagure. I very likely wouldn't create an account there just to forward patches to a random kernel subsystem/driver eventually hosted there. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:58 ` Mauro Carvalho Chehab @ 2018-09-17 14:18 ` Christoph Hellwig 2018-09-17 14:50 ` Geert Uytterhoeven 2018-09-17 14:18 ` Laurent Pinchart 2018-09-17 16:50 ` Joe Perches 2 siblings, 1 reply; 162+ messages in thread From: Christoph Hellwig @ 2018-09-17 14:18 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Christoph Hellwig, ksummit-discuss On Mon, Sep 17, 2018 at 10:58:05AM -0300, Mauro Carvalho Chehab wrote: > > > specifically). The only problem is that people tend to omit context, > > > because they assume that you see the code or previous messages that they > > > see in the web interface, which you do not. > > > > The major problem with github is that as far as I can tell there is no > > way to interact with it without creating an account. > > Well, the same happens with moderated mailing lists. There are a > lot of them: > $ git grep moderated MAINTAINERS|wc -l > 221 Note that moderated doesn't mean that it always rejects non-subscribers. For example I post to linux-arm-kernel frequently, and my mails always seem to make it through with a delay. Other lists seems to reject non-subcribers, but the personal email addresses of the maintainers still allow to submit patches without any signup. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 14:18 ` Christoph Hellwig @ 2018-09-17 14:50 ` Geert Uytterhoeven 2018-09-17 15:21 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-17 14:50 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Mauro Carvalho Chehab, ksummit-discuss Hi Christoph, On Mon, Sep 17, 2018 at 4:18 PM Christoph Hellwig <hch@infradead.org> wrote: > On Mon, Sep 17, 2018 at 10:58:05AM -0300, Mauro Carvalho Chehab wrote: > > > > specifically). The only problem is that people tend to omit context, > > > > because they assume that you see the code or previous messages that they > > > > see in the web interface, which you do not. > > > > > > The major problem with github is that as far as I can tell there is no > > > way to interact with it without creating an account. > > > > Well, the same happens with moderated mailing lists. There are a > > lot of them: > > $ git grep moderated MAINTAINERS|wc -l > > 221 > > Note that moderated doesn't mean that it always rejects non-subscribers. > For example I post to linux-arm-kernel frequently, and my mails always > seem to make it through with a delay. linux-arm-kernel is a gateway to many maintainers, most of them will take your patches fine. But if it is for core ARM, it still has to be submitted to the ARM patch system separately. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 14:50 ` Geert Uytterhoeven @ 2018-09-17 15:21 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 15:21 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Christoph Hellwig, ksummit-discuss Em Mon, 17 Sep 2018 16:50:23 +0200 Geert Uytterhoeven <geert@linux-m68k.org> escreveu: > Hi Christoph, > > On Mon, Sep 17, 2018 at 4:18 PM Christoph Hellwig <hch@infradead.org> wrote: > > On Mon, Sep 17, 2018 at 10:58:05AM -0300, Mauro Carvalho Chehab wrote: > > > > > specifically). The only problem is that people tend to omit context, > > > > > because they assume that you see the code or previous messages that they > > > > > see in the web interface, which you do not. > > > > > > > > The major problem with github is that as far as I can tell there is no > > > > way to interact with it without creating an account. > > > > > > Well, the same happens with moderated mailing lists. There are a > > > lot of them: > > > $ git grep moderated MAINTAINERS|wc -l > > > 221 > > > > Note that moderated doesn't mean that it always rejects non-subscribers. > > For example I post to linux-arm-kernel frequently, and my mails always > > seem to make it through with a delay. Yeah, same happens to me. I stopped receiving emails from several such lists. Not sure if I ended by subscribing to it (in order to actively participate on some discussions) or if my email was simply whitelisted. > linux-arm-kernel is a gateway to many maintainers, most of them will take > your patches fine. > > But if it is for core ARM, it still has to be submitted to the ARM patch system > separately. Provided that get_maintainers.pl gets it, and someone will manually whitelist either my e-mail or my patch on an eventual patch submission, no issues with that. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:58 ` Mauro Carvalho Chehab 2018-09-17 14:18 ` Christoph Hellwig @ 2018-09-17 14:18 ` Laurent Pinchart 2018-09-17 16:50 ` Joe Perches 2 siblings, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-17 14:18 UTC (permalink / raw) To: ksummit-discuss; +Cc: Mauro Carvalho Chehab, Christoph Hellwig On Monday, 17 September 2018 16:58:05 EEST Mauro Carvalho Chehab wrote: > Em Mon, 17 Sep 2018 06:29:08 -0700 Christoph Hellwig escreveu: > > On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote: > >>> Btw, on a quick look, it seems that github has/had an email > >>> > >>> interface already: > >>> https://blog.github.com/2011-03-10-reply-to-comments-from-email/ > >> > >> I only interact with issues posted to github via email (alpine > >> specifically). The only problem is that people tend to omit context, > >> because they assume that you see the code or previous messages that they > >> see in the web interface, which you do not. > > > > The major problem with github is that as far as I can tell there is no > > way to interact with it without creating an account. > > Well, the same happens with moderated mailing lists. There are a > lot of them: > $ git grep moderated MAINTAINERS|wc -l > 221 I disagree, I think that's very different. A moderated mailing list requires you to subscribe, but then doesn't require you to authenticate for every interaction, while a web UI will require authentication. > Except when it is something that I really want to be merged > (e. g. something that affects my own machines or I have a demand > from my employer), when a perfectly fine patch I sent is ignored > by such lists, I just ignore whatever e-mail I receive from their > mailman interface, and I assume that, if I don't receive any reply > from a human, either the maintainers of such subsystem(s) accepted > it or they just don't care enough. So, if it is patch affecting > media, I just apply after a reasonable reviewing time. > > In the case of github-like interfaces, I would do the same: I > would copy the maintainer(s) and just ignore any "non-subscriber's > warning" kind of e-mail. There would be no such warning, as you wouldn't be able to post a message in the first place. > That's actually one difference in this case: while on moderated > ML you need to be added to each individual ML in order to send > e-mails, on a web-based interface, just one subscription is > enough for all projects hosted there, and there are a lot less > git hosting servers than email mailing lists. At the moment there is. If we start hosting gitlab instances for different subsystems, the situation will become very different. > So, in the specific case of github, I wouldn't have any issues, as I had to > create an account there due to other purposes. Yet, I don't have any > need right now to have an account on gitlab or Pagure. I very > likely wouldn't create an account there just to forward patches > to a random kernel subsystem/driver eventually hosted there. Exactly my point :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:58 ` Mauro Carvalho Chehab 2018-09-17 14:18 ` Christoph Hellwig 2018-09-17 14:18 ` Laurent Pinchart @ 2018-09-17 16:50 ` Joe Perches 2 siblings, 0 replies; 162+ messages in thread From: Joe Perches @ 2018-09-17 16:50 UTC (permalink / raw) To: Mauro Carvalho Chehab, Christoph Hellwig; +Cc: ksummit-discuss On Mon, 2018-09-17 at 10:58 -0300, Mauro Carvalho Chehab wrote: > Em Mon, 17 Sep 2018 06:29:08 -0700 > Christoph Hellwig <hch@infradead.org> escreveu: > > > On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote: > > > > Btw, on a quick look, it seems that github has/had an email > > > > interface already: > > > > https://blog.github.com/2011-03-10-reply-to-comments-from-email/ > > > > > > I only interact with issues posted to github via email (alpine > > > specifically). The only problem is that people tend to omit context, > > > because they assume that you see the code or previous messages that they > > > see in the web interface, which you do not. > > > > The major problem with github is that as far as I can tell there is no > > way to interact with it without creating an account. > > Well, the same happens with moderated mailing lists. There are a > lot of them: > $ git grep moderated MAINTAINERS|wc -l > 221 moderation doesn't mean rejection by non-subscribers and it's nowhere near that number. $ git grep -i moderated MAINTAINERS | sort | uniq -c | wc -l 32 Most all of those have public archives too. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:04 ` Mauro Carvalho Chehab 2018-09-17 13:10 ` Julia Lawall @ 2018-09-17 14:14 ` Laurent Pinchart 2018-09-17 14:59 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 162+ messages in thread From: Laurent Pinchart @ 2018-09-17 14:14 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss On Monday, 17 September 2018 16:04:13 EEST Mauro Carvalho Chehab wrote: > Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven escreveu: > > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab wrote: > >> Em Tue, 11 Sep 2018 02:05:06 +0300 Laurent Pinchart escreveu: > >>> On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote: > >>>> On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > >>>>> On my side, there are three very important features that a > >>>>> communication system should have: > >>>>> > >>>>> - It should be push-based. I don't want to have to log in and pull > >>>>> information from web UIs. > >>>>> > >>>>> - It should be customizable, offering an easy way to script > >>>>> review, and patch and pull request handling. > >>>>> > >>>>> - It should offer an offline mode. Lots of us travel a lot or > >>>>> generally have to work without an internet connection more often > >>>>> than we would like, so any solution that requires being online > >>>>> won't work. > >>>>> > >>>>> Emails provide all that, there may be good options I just fail to > >>>>> think about right now. > >>>> > >>>> One more requirement I would add is that messages should be > >>>> archived, and should have a first class search system. We should be > >>>> able to reference a commit id in a communications thread, and then a > >>>> search for that commit id (or commit description) should be able to > >>>> turn up that message, and from there, be able to see the rest of the > >>>> messages on that thread. > >>>> > >>>> Being able to find the "legislative history" behind a particular > >>>> change in the kernel is super-important. > >>> > >>> Fully agreed. I would even go one step further, I'd like a system > >>> where relationships between messages are kept. This obviously means > >>> linking patches from the same series, but also detecting new versions > >>> of patch series (to the extent possible, as already discussed in this > >>> mail thread). > >> > >> Let me go one step down. > >> > >> While I do agree that the main Kernel development should happen via > >> email on the foreseen future, Why e-mail would be a mandatory > >> requirement for all kinds of Kernel development? Nothing in the list of requirements above mandates e-mail, it just happens that e-mail fits them at the moment. > >> I don't believe that a single development model fits all cases. > >> > >> Let's say that someone is using something like github to manage the > >> development of a single driver - or even a low traffic subsystem. Please note that Daniel specifically mentioned gitlab, not github, and explained how the github model wouldn't fit our needs. > >> The communication traffic between the developers there is usually > >> not relevant (nor wanted) at LKML. Not on LKML, but it should be public, searchable and mirrored, not hidden behind an authentication, or stored in a single location. > >> What we usually do on normal subsystems is to have those discussions > >> "filtered" on a separate mailing list. I don't see why not use a > >> web-based interface for such purpose. There are multiple reasons. One of them is that you'll lose the whole history the day the project is deleted from gitlab, github or any other single provider. Another one is that it requires drive-by contributors to log in to different web UIs to submit patches to different subsystems (and from my point of view even a single web UI is too much). As soon as you require people to pull content instead of getting it in their mailbox (or whatever alternative to e-mail we would come up with), you've lost. > >> Btw, that's not that different on what happens on some companies that > >> do their driver developments internally. They do whatever they want > >> when developing the driver. Only when they have something ready they > >> use e-mail. And we've told companies for years that they should develop in the open. It has borne some fruits (albeit not enough), so let's not go back to where we were before. > >> A github-like interface is actually better than that, as people > >> interested on such driver/subsystem could contribute earlier than > >> on a closed doors model, as the discussions can be seen publicly. > >> > >> On both cases, the only relevant discussions for LKML and for the > >> Kernel maintainer that would be taking their patches are when they > >> send a pull request upstream. > > > > Development doesn't stop when the driver has been developed and merged > > in mainline. > > Yeah, sure. > > > It's a good idea to always CC lkml when submitting a patch for a bug in > > the driver. > > True, but this doesn't always happen. If it happens, nothing prevents > that someone would use a "man-handled copy-and-paste interface" > between e-mail and web. > > Btw, this happens already, even with e-mail: from time to time, we > receive bug reports on media from something reported via distro bug > tracks (bugzilla, Trac, ...). > > Even when the bug tracking system has an email interface > (Red Hat BZ has, for example), it is really rare to use email > for tracked bug reports (even from Kernel.org bugzilla). > > What works in practice for such bugs is that we end by using web > interfaces if we need to talk about the bug inside the tracker > system, or via e-mail if we want to talk about it subsystem-wide. > > Sub-optimal, but it works. That makes our work more difficult, due to the lack of integration between the bug tracker and our usual workflow. Bugs reported through bug trackers are often handled as second-class citizens for that reason. > The same would happen if the development discussions would happen > inside a web interface like github/gitlab. Of course, the maintainer > would still need to be reachable by e-mail. If your point is that it would be similarly painful, I agree :-) (or to be honest I'm concerned it would be even more painful, but certainly not less). > >> Granted, there will be some drawbacks if email interface is not > >> available if such development community would need to talk with > >> other subsystems. So, yes, it is desirable to have an e-mail > >> interface, as otherwise a human would have to handle such things > >> manually, but, again, for low traffic development, such things > >> would be doable. > > > > And once the driver has been integrated, maintenance (changed > > subsystem APIs, cleanups, ...) will need be done, on a larger scale. > > True, but still doable. > > See, I don't have myself any plans to use something like github > for Kernel development. Yet, I think we should be open to work > with people that would prefer to work with such model. > > Btw, on a quick look, it seems that github has/had an email > interface already: > https://blog.github.com/2011-03-10-reply-to-comments-from-email/ > > It seems that there are ways to create new issues there via e-mail > too, although currently it sounds a little hacky (requiring either > to run an script or to add a github bot user to the project): > > https://stackoverflow.com/questions/25051686/create-github-issue-from-fresh > desk If you want to look at specific features I'd recommend checking gitlab and not github, for the reasons outlined by Daniel. As explained before, there's nothing wrong in my opinion in providing a web UI for some features as an optional alternative to e-mail, as long as proper e- mail gateways are in place to make e-mail-based workflow mostly undisturbed. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 14:14 ` Laurent Pinchart @ 2018-09-17 14:59 ` Mauro Carvalho Chehab 2018-09-17 22:39 ` Dave Airlie 2018-09-18 8:24 ` Eric W. Biederman 0 siblings, 2 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 14:59 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit-discuss Em Mon, 17 Sep 2018 17:14:29 +0300 Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > On Monday, 17 September 2018 16:04:13 EEST Mauro Carvalho Chehab wrote: > > Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven escreveu: > > > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab wrote: > > >> Em Tue, 11 Sep 2018 02:05:06 +0300 Laurent Pinchart escreveu: > > >>> On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote: > > >>>> On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote: > > >>>>> On my side, there are three very important features that a > > >>>>> communication system should have: > > >>>>> > > >>>>> - It should be push-based. I don't want to have to log in and pull > > >>>>> information from web UIs. > > >>>>> > > >>>>> - It should be customizable, offering an easy way to script > > >>>>> review, and patch and pull request handling. > > >>>>> > > >>>>> - It should offer an offline mode. Lots of us travel a lot or > > >>>>> generally have to work without an internet connection more often > > >>>>> than we would like, so any solution that requires being online > > >>>>> won't work. > > >>>>> > > >>>>> Emails provide all that, there may be good options I just fail to > > >>>>> think about right now. > > >>>> > > >>>> One more requirement I would add is that messages should be > > >>>> archived, and should have a first class search system. We should be > > >>>> able to reference a commit id in a communications thread, and then a > > >>>> search for that commit id (or commit description) should be able to > > >>>> turn up that message, and from there, be able to see the rest of the > > >>>> messages on that thread. > > >>>> > > >>>> Being able to find the "legislative history" behind a particular > > >>>> change in the kernel is super-important. > > >>> > > >>> Fully agreed. I would even go one step further, I'd like a system > > >>> where relationships between messages are kept. This obviously means > > >>> linking patches from the same series, but also detecting new versions > > >>> of patch series (to the extent possible, as already discussed in this > > >>> mail thread). > > >> > > >> Let me go one step down. > > >> > > >> While I do agree that the main Kernel development should happen via > > >> email on the foreseen future, Why e-mail would be a mandatory > > >> requirement for all kinds of Kernel development? > > Nothing in the list of requirements above mandates e-mail, it just happens > that e-mail fits them at the moment. > > > >> I don't believe that a single development model fits all cases. > > >> > > >> Let's say that someone is using something like github to manage the > > >> development of a single driver - or even a low traffic subsystem. > > Please note that Daniel specifically mentioned gitlab, not github, and > explained how the github model wouldn't fit our needs. Yes, I saw Daniel's email. Well, gitlab may fit better for DRM, but other developers may have different preferences [1]. I don't think we should (or we can) force everybody to use a single development model. [1] IMO, adopting gitlab/github/whatever-web-UI for a high traffic subsystem like DRM or media is a completely different beast: one has to do enough tests that this would work before start any migration, and it should ensure that the usual e-mail workflow submission and patch review will keep working as before, as the rest of the Kernel community won't change their workflow. > > >> The communication traffic between the developers there is usually > > >> not relevant (nor wanted) at LKML. > > Not on LKML, but it should be public, searchable and mirrored, not hidden > behind an authentication, or stored in a single location. Yeah, being public and searchable are important features. However, nowadays, the concept of "stored in a single location" is something that doesn't make much sense: most of stuff are stored on clouds, specially if one is using a big service provider. On a cloud service, the concept of "mirrored" also is not relevant: a single URL usually is handled by multiple servers. Usually, it is invisible to the users what is the real infrastructure behind the service. > > >> What we usually do on normal subsystems is to have those discussions > > >> "filtered" on a separate mailing list. I don't see why not use a > > >> web-based interface for such purpose. > > There are multiple reasons. One of them is that you'll lose the whole history > the day the project is deleted from gitlab, github or any other single > provider. This can happen whatever infra is used. That's why the git logs should be clear enough to not depend on it. I'm pretty sure that, whatever we use nowadays (even mirrored ML logs) will some day be replaced by something else. Try to seek, for example, for the old usenet messages. The only thing that is more warranted to survive as time goes by are the patch logs. > Another one is that it requires drive-by contributors to log in to > different web UIs to submit patches to different subsystems (and from my point > of view even a single web UI is too much). As soon as you require people to > pull content instead of getting it in their mailbox (or whatever alternative > to e-mail we would come up with), you've lost. This is a valid point: whatever development process is used, drive-by contributors should be allowed to send e-mails without needing to subscribe (neither to a moderated list nor to a web-UI). I don't care how the maintainer will handle such patches, provided that they will be properly handled. > > >> Btw, that's not that different on what happens on some companies that > > > It's a good idea to always CC lkml when submitting a patch for a bug in > > > the driver. > > > > True, but this doesn't always happen. If it happens, nothing prevents > > that someone would use a "man-handled copy-and-paste interface" > > between e-mail and web. > > > > Btw, this happens already, even with e-mail: from time to time, we > > receive bug reports on media from something reported via distro bug > > tracks (bugzilla, Trac, ...). > > > > Even when the bug tracking system has an email interface > > (Red Hat BZ has, for example), it is really rare to use email > > for tracked bug reports (even from Kernel.org bugzilla). > > > > What works in practice for such bugs is that we end by using web > > interfaces if we need to talk about the bug inside the tracker > > system, or via e-mail if we want to talk about it subsystem-wide. > > > > Sub-optimal, but it works. > > That makes our work more difficult, due to the lack of integration between the > bug tracker and our usual workflow. Bugs reported through bug trackers are > often handled as second-class citizens for that reason. > > > The same would happen if the development discussions would happen > > inside a web interface like github/gitlab. Of course, the maintainer > > would still need to be reachable by e-mail. > > If your point is that it would be similarly painful, I agree :-) (or to be > honest I'm concerned it would be even more painful, but certainly not less). Actually, I think it could be less painful on drivers than git+kernel BZ if the developers of such driver/subsystem are all using their web-UI and they only receive a handful contributions from "outside world", as the bugs will be tracked by the same interface. That won't be the case of larger subsystems like media, DRM, net, sound, etc. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 14:59 ` Mauro Carvalho Chehab @ 2018-09-17 22:39 ` Dave Airlie 2018-09-17 23:04 ` James Bottomley ` (2 more replies) 2018-09-18 8:24 ` Eric W. Biederman 1 sibling, 3 replies; 162+ messages in thread From: Dave Airlie @ 2018-09-17 22:39 UTC (permalink / raw) To: mchehab+samsung; +Cc: ksummit > This is a valid point: whatever development process is used, drive-by > contributors should be allowed to send e-mails without needing to subscribe > (neither to a moderated list nor to a web-UI). I don't care how the > maintainer will handle such patches, provided that they will be properly > handled. > It really depends on what type of one-off contributor they are. Setting up git send-email isn't trivial for everyone, if you are a gmail user and work for a company that doesn't embrace smtp so much, then having a webui and https git access will be a lot easier for one-off contributions. Beware of thinking our setup with email is in any way simple for a newcomer to setup properly. Dave. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 22:39 ` Dave Airlie @ 2018-09-17 23:04 ` James Bottomley 2018-09-18 8:00 ` Daniel Vetter 2018-09-18 7:37 ` Nicolas Ferre 2018-09-18 10:38 ` Laurent Pinchart 2 siblings, 1 reply; 162+ messages in thread From: James Bottomley @ 2018-09-17 23:04 UTC (permalink / raw) To: Dave Airlie, mchehab+samsung; +Cc: ksummit On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.com> wrote: >> This is a valid point: whatever development process is used, drive-by >> contributors should be allowed to send e-mails without needing to >subscribe >> (neither to a moderated list nor to a web-UI). I don't care how the >> maintainer will handle such patches, provided that they will be >properly >> handled. >> >It really depends on what type of one-off contributor they are. > >Setting up git send-email isn't trivial for everyone, if you are a >gmail user and work for a company that doesn't embrace smtp so much, >then having a webui and https git access will be a lot easier for >one-off contributions. Agree with this but that's why I don't use git-send-email >Beware of thinking our setup with email is in any way simple for a >newcomer to setup properly. Right, but there are many other ways of doing this which still work with mailing lists. James >Dave. >_______________________________________________ >Ksummit-discuss mailing list >Ksummit-discuss@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 23:04 ` James Bottomley @ 2018-09-18 8:00 ` Daniel Vetter 2018-09-18 11:16 ` James Bottomley 0 siblings, 1 reply; 162+ messages in thread From: Daniel Vetter @ 2018-09-18 8:00 UTC (permalink / raw) To: James Bottomley; +Cc: Mauro Carvalho Chehab, ksummit On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.com> wrote: >>> This is a valid point: whatever development process is used, drive-by >>> contributors should be allowed to send e-mails without needing to >>subscribe >>> (neither to a moderated list nor to a web-UI). I don't care how the >>> maintainer will handle such patches, provided that they will be >>properly >>> handled. >>> >>It really depends on what type of one-off contributor they are. >> >>Setting up git send-email isn't trivial for everyone, if you are a >>gmail user and work for a company that doesn't embrace smtp so much, >>then having a webui and https git access will be a lot easier for >>one-off contributions. > > Agree with this but that's why I don't use git-send-email > >>Beware of thinking our setup with email is in any way simple for a >>newcomer to setup properly. > > Right, but there are many other ways of doing this which still work with mailing lists. Aside from bare diffs stuffed into plaintext mails directly (which I is a lot harder to set up than git send-email for new people), what else is there that works with mailing lists? I'd be great if we have other options here, since it is a fairly annoying problem for us. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 8:00 ` Daniel Vetter @ 2018-09-18 11:16 ` James Bottomley 2018-09-18 15:26 ` Randy Dunlap 2018-09-18 16:47 ` Tim.Bird 0 siblings, 2 replies; 162+ messages in thread From: James Bottomley @ 2018-09-18 11:16 UTC (permalink / raw) To: Daniel Vetter; +Cc: Mauro Carvalho Chehab, ksummit On Tue, 2018-09-18 at 10:00 +0200, Daniel Vetter wrote: > On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.co > > m> wrote: > > > > This is a valid point: whatever development process is used, > > > > drive-by contributors should be allowed to send e-mails without > > > > needing to > > > > > > subscribe > > > > (neither to a moderated list nor to a web-UI). I don't care how > > > > the maintainer will handle such patches, provided that they > > > > will be > > > > > > properly handled. > > > > > > > > > > It really depends on what type of one-off contributor they are. > > > > > > Setting up git send-email isn't trivial for everyone, if you are > > > a gmail user and work for a company that doesn't embrace smtp so > > > much, then having a webui and https git access will be a lot > > > easier for one-off contributions. > > > > Agree with this but that's why I don't use git-send-email > > > > > Beware of thinking our setup with email is in any way simple for > > > a newcomer to setup properly. > > > > Right, but there are many other ways of doing this which still work > > with mailing lists. > > Aside from bare diffs stuffed into plaintext mails directly (which I > is a lot harder to set up than git send-email for new people), Well, that is how I do it: git format-patch followed by preformatted text insertion in evolution. I've got to say I don't find it at all hard, but I do understand if you use outlook or gmail it can be a pain. > what else is there that works with mailing lists? I'd be great if we > have other options here, since it is a fairly annoying problem for > us. This is more about mail tools than actual lists, isn't it? In which case I find the Documentation/email-clients.txt and invaluable resource to point people to (wait, where is it now, ah: Documentation/process/email-clients.rst) James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 11:16 ` James Bottomley @ 2018-09-18 15:26 ` Randy Dunlap 2018-09-18 16:47 ` Tim.Bird 1 sibling, 0 replies; 162+ messages in thread From: Randy Dunlap @ 2018-09-18 15:26 UTC (permalink / raw) To: James Bottomley, Daniel Vetter; +Cc: Mauro Carvalho Chehab, ksummit On 9/18/18 4:16 AM, James Bottomley wrote: > On Tue, 2018-09-18 at 10:00 +0200, Daniel Vetter wrote: >> On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley >> <James.Bottomley@hansenpartnership.com> wrote: >>> On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.co >>> m> wrote: >>>>> This is a valid point: whatever development process is used, >>>>> drive-by contributors should be allowed to send e-mails without >>>>> needing to >>>> >>>> subscribe >>>>> (neither to a moderated list nor to a web-UI). I don't care how >>>>> the maintainer will handle such patches, provided that they >>>>> will be >>>> >>>> properly handled. >>>>> >>>> >>>> It really depends on what type of one-off contributor they are. >>>> >>>> Setting up git send-email isn't trivial for everyone, if you are >>>> a gmail user and work for a company that doesn't embrace smtp so >>>> much, then having a webui and https git access will be a lot >>>> easier for one-off contributions. >>> >>> Agree with this but that's why I don't use git-send-email >>> >>>> Beware of thinking our setup with email is in any way simple for >>>> a newcomer to setup properly. >>> >>> Right, but there are many other ways of doing this which still work >>> with mailing lists. >> >> Aside from bare diffs stuffed into plaintext mails directly (which I >> is a lot harder to set up than git send-email for new people), > > Well, that is how I do it: git format-patch followed by preformatted > text insertion in evolution. I've got to say I don't find it at all > hard, but I do understand if you use outlook or gmail it can be a pain. Ack. I use git send-email for a series, but for single patches, it's more of a pain than just using an email client. >> what else is there that works with mailing lists? I'd be great if we >> have other options here, since it is a fairly annoying problem for >> us. > > This is more about mail tools than actual lists, isn't it? In which > case I find the Documentation/email-clients.txt and invaluable resource > to point people to (wait, where is it now, ah: > Documentation/process/email-clients.rst) Thanks. -- ~Randy ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 11:16 ` James Bottomley 2018-09-18 15:26 ` Randy Dunlap @ 2018-09-18 16:47 ` Tim.Bird 2018-09-18 16:59 ` Konstantin Ryabitsev 1 sibling, 1 reply; 162+ messages in thread From: Tim.Bird @ 2018-09-18 16:47 UTC (permalink / raw) To: James.Bottomley, daniel.vetter; +Cc: mchehab+samsung, ksummit-discuss > -----Original Message----- > From: James Bottomley > > On Tue, 2018-09-18 at 10:00 +0200, Daniel Vetter wrote: > > On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: > > > On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.co > > > m> wrote: > > > > > This is a valid point: whatever development process is used, > > > > > drive-by contributors should be allowed to send e-mails without > > > > > needing to > > > > > > > > subscribe > > > > > (neither to a moderated list nor to a web-UI). I don't care how > > > > > the maintainer will handle such patches, provided that they > > > > > will be > > > > > > > > properly handled. > > > > > > > > > > > > > It really depends on what type of one-off contributor they are. > > > > > > > > Setting up git send-email isn't trivial for everyone, if you are > > > > a gmail user and work for a company that doesn't embrace smtp so > > > > much, then having a webui and https git access will be a lot > > > > easier for one-off contributions. > > > > > > Agree with this but that's why I don't use git-send-email > > > > > > > Beware of thinking our setup with email is in any way simple for > > > > a newcomer to setup properly. > > > > > > Right, but there are many other ways of doing this which still work > > > with mailing lists. > > > > Aside from bare diffs stuffed into plaintext mails directly (which I > > is a lot harder to set up than git send-email for new people), > > Well, that is how I do it: git format-patch followed by preformatted > text insertion in evolution. I've got to say I don't find it at all > hard, but I do understand if you use outlook or gmail it can be a pain. > > > what else is there that works with mailing lists? I'd be great if we > > have other options here, since it is a fairly annoying problem for > > us. > > This is more about mail tools than actual lists, isn't it? In which > case I find the Documentation/email-clients.txt and invaluable resource > to point people to (wait, where is it now, ah: > Documentation/process/email-clients.rst) Well, it's more than just the mail tool - it's the entire enterprise e-mail infrastructure where problems can crop up. Sony's IT department recently installed a system to help prevent phishing attacks which re-writes all the URLs in every e-mail that goes through the system. This is patch-unfriendly, to say the least. I'm working with IT to try to get myself exempted from this "service", but it affects every Sony employee who wishes to use corporate e-mail to collaborate with upstream. Unfortunately, this type of thing is fairly common. For my part, I wish there were a gateway I could send through, that would undo all the mumbo-jumbo that exchange and the like introduce (text re-flowing, uuencoding, url-rewriting, etc.) Mainstream e-mail infrastructure implementations are increasingly averse to just delivering raw text from one point to another, so the fundamental assumption that e-mail is a reliable text delivery service is increasingly unfounded. -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:47 ` Tim.Bird @ 2018-09-18 16:59 ` Konstantin Ryabitsev 2018-09-18 17:08 ` Tim.Bird 0 siblings, 1 reply; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-18 16:59 UTC (permalink / raw) To: Tim.Bird; +Cc: James.Bottomley, ksummit-discuss, mchehab+samsung On Tue, Sep 18, 2018 at 04:47:00PM +0000, Tim.Bird@sony.com wrote: >For my part, I wish there were a gateway I could send through, that >would >undo all the mumbo-jumbo that exchange and the like introduce (text re-flowing, >uuencoding, url-rewriting, etc.) If you have a kernel.org account (I know you don't, but I'm sure you can probably get one, since you used to have one in the past), you can use mail.kernel.org for sending outgoing mail: https://korg.wiki.kernel.org/userdoc/mail#sending_outgoing_mail -K ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:59 ` Konstantin Ryabitsev @ 2018-09-18 17:08 ` Tim.Bird 2018-09-18 17:12 ` Tim.Bird 2018-09-18 17:31 ` Konstantin Ryabitsev 0 siblings, 2 replies; 162+ messages in thread From: Tim.Bird @ 2018-09-18 17:08 UTC (permalink / raw) To: konstantin; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss > -----Original Message----- > From: Konstantin Ryabitsev > On Tue, Sep 18, 2018 at 04:47:00PM +0000, Tim.Bird@sony.com wrote: > >For my part, I wish there were a gateway I could send through, that > >would > >undo all the mumbo-jumbo that exchange and the like introduce (text re- > flowing, > >uuencoding, url-rewriting, etc.) > > If you have a kernel.org account (I know you don't, but I'm sure you can > probably get one, since you used to have one in the past), you can use > mail.kernel.org for sending outgoing mail: > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing- > 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7- > GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y- > INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY- > Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e= > Thank you for the offer. However, while that's a solution that might work for me (modulo my ability to punch my way through the firewall to that mail server), it doesn't scale or help my colleagues at Sony who I'm trying to remove barriers for as well. I'm senior enough at Sony to have a somewhat different situation than other Sony Linux developers, however I intentionally work through the IT department and use commonly provided tools here in order to 1) understand the hurdles other developers at Sony have, and 2) work on general solutions. -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:08 ` Tim.Bird @ 2018-09-18 17:12 ` Tim.Bird 2018-09-18 17:31 ` Konstantin Ryabitsev 1 sibling, 0 replies; 162+ messages in thread From: Tim.Bird @ 2018-09-18 17:12 UTC (permalink / raw) To: Tim.Bird, konstantin; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss > -----Original Message----- > From: Tim.Bird@sony.com > > -----Original Message----- > > From: Konstantin Ryabitsev > > On Tue, Sep 18, 2018 at 04:47:00PM +0000, Tim.Bird@sony.com wrote: > > >For my part, I wish there were a gateway I could send through, that > > >would > > >undo all the mumbo-jumbo that exchange and the like introduce (text re- > > flowing, > > >uuencoding, url-rewriting, etc.) > > > > If you have a kernel.org account (I know you don't, but I'm sure you can > > probably get one, since you used to have one in the past), you can use > > mail.kernel.org for sending outgoing mail: > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing- > > 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7- > > GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y- > > INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY- > > Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e= And yes - I left this URL re-write here intentionally to let you-all see my pain. Misery loves company. :-) -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:08 ` Tim.Bird 2018-09-18 17:12 ` Tim.Bird @ 2018-09-18 17:31 ` Konstantin Ryabitsev 2018-09-18 17:42 ` Tim.Bird ` (3 more replies) 1 sibling, 4 replies; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-18 17:31 UTC (permalink / raw) To: Tim.Bird; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote: >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing- >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7- >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y- >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY- >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e= Ick. >Thank you for the offer. However, while that's a solution that might >work >for me (modulo my ability to punch my way through the firewall to that mail >server), it doesn't scale or help my colleagues at Sony who I'm trying to >remove barriers for as well. I'm senior enough at Sony to have a somewhat >different situation than other Sony Linux developers, however I intentionally >work through the IT department and use commonly provided tools here >in order to 1) understand the hurdles other developers at Sony have, and >2) work on general solutions. Ah, I understand your situation better now. So, what if we imagine that there's an imaginary web tool that does this: 1. Allows people to generate an account 2. Verifies their email address 3. Instructs people how to generate a patch or series of patches 4. Gives a way to upload generated patches 5. Runs checkpatch to make sure there are no errors 6. Runs get_maintainer to find out where the patch(es) should be sent to 7. (Does more imaginary magic, such as looking up message-id references) 8. Mails it out Would that be useful or solve any problems? Or would that, on the contrary, create more problems than it solves? -K ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:31 ` Konstantin Ryabitsev @ 2018-09-18 17:42 ` Tim.Bird 2018-09-18 17:55 ` Konstantin Ryabitsev 2018-09-18 17:47 ` Geert Uytterhoeven ` (2 subsequent siblings) 3 siblings, 1 reply; 162+ messages in thread From: Tim.Bird @ 2018-09-18 17:42 UTC (permalink / raw) To: konstantin; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss > -----Original Message----- > From: Konstantin Ryabitsev > > On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote: > >> https://urldefense.proofpoint.com/v2/url?u=https- > >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing- > >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7- > >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y- > >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY- > >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e= > > Ick. Thanks. I appreciate the sympathy. :-) > > >Thank you for the offer. However, while that's a solution that might > >work > >for me (modulo my ability to punch my way through the firewall to that mail > >server), it doesn't scale or help my colleagues at Sony who I'm trying to > >remove barriers for as well. I'm senior enough at Sony to have a somewhat > >different situation than other Sony Linux developers, however I > intentionally > >work through the IT department and use commonly provided tools here > >in order to 1) understand the hurdles other developers at Sony have, and > >2) work on general solutions. > > Ah, I understand your situation better now. > > So, what if we imagine that there's an imaginary web tool that does > this: > > 1. Allows people to generate an account > 2. Verifies their email address > 3. Instructs people how to generate a patch or series of patches > 4. Gives a way to upload generated patches > 5. Runs checkpatch to make sure there are no errors > 6. Runs get_maintainer to find out where the patch(es) should be sent to > 7. (Does more imaginary magic, such as looking up message-id references) > 8. Mails it out > > Would that be useful or solve any problems? Or would that, on the > contrary, create more problems than it solves? Konstantin, I feel like this thread re-converged and you proposed the exact thing I just expressed interest in to Linus. You were probably writing your message at the same time I was writing mine. Wow! Personally, I feel this would be a GREAT thing. I'm not a kernel maintainer, and I think that there would have to be maintainer buy-in for this. So I'm interested what others think. -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:42 ` Tim.Bird @ 2018-09-18 17:55 ` Konstantin Ryabitsev 2018-09-18 18:58 ` Tim.Bird 0 siblings, 1 reply; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-18 17:55 UTC (permalink / raw) To: Tim.Bird; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 1574 bytes --] On Tue, Sep 18, 2018 at 05:42:57PM +0000, Tim.Bird@sony.com wrote: >> So, what if we imagine that there's an imaginary web tool that does >> this: >> >> 1. Allows people to generate an account >> 2. Verifies their email address >> 3. Instructs people how to generate a patch or series of patches >> 4. Gives a way to upload generated patches >> 5. Runs checkpatch to make sure there are no errors >> 6. Runs get_maintainer to find out where the patch(es) should be sent to >> 7. (Does more imaginary magic, such as looking up message-id references) >> 8. Mails it out >> >> Would that be useful or solve any problems? Or would that, on the >> contrary, create more problems than it solves? > >Konstantin, > >I feel like this thread re-converged and you proposed the exact thing I just >expressed interest in to Linus. You were probably writing your message at >the same time I was writing mine. Wow! > >Personally, I feel this would be a GREAT thing. Okay, tacking on some more imaginary features on top of this, let's say it also had a way to add a remotely hosted git tree to your account, e.g.: https://github.com/somecorp/linux-corpfidget.git alias corpfidget It could then offer a CLI utility to issue a command like this using the https API: vapor-git-thingy -g corpfidget -r 1234abcd..5678dcba -v2 -c coverletter.txt That would do the same as the above, plus do the patch generation itself... Okay, I think I might be able to scrape up funding to get this built once I put this into a more presentable form. -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:55 ` Konstantin Ryabitsev @ 2018-09-18 18:58 ` Tim.Bird 2018-09-18 19:24 ` Konstantin Ryabitsev 0 siblings, 1 reply; 162+ messages in thread From: Tim.Bird @ 2018-09-18 18:58 UTC (permalink / raw) To: konstantin; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss > -----Original Message----- > From: Konstantin Ryabitsev > On Tue, Sep 18, 2018 at 05:42:57PM +0000, Tim.Bird@sony.com wrote: > >> So, what if we imagine that there's an imaginary web tool that does > >> this: > >> > >> 1. Allows people to generate an account > >> 2. Verifies their email address > >> 3. Instructs people how to generate a patch or series of patches > >> 4. Gives a way to upload generated patches > >> 5. Runs checkpatch to make sure there are no errors > >> 6. Runs get_maintainer to find out where the patch(es) should be sent to > >> 7. (Does more imaginary magic, such as looking up message-id references) > >> 8. Mails it out > >> > >> Would that be useful or solve any problems? Or would that, on the > >> contrary, create more problems than it solves? > > > >Konstantin, > > > >I feel like this thread re-converged and you proposed the exact thing I just > >expressed interest in to Linus. You were probably writing your message at > >the same time I was writing mine. Wow! > > > >Personally, I feel this would be a GREAT thing. > > Okay, tacking on some more imaginary features on top of this, let's say > it also had a way to add a remotely hosted git tree to your account, > e.g.: > > https://github.com/somecorp/linux-corpfidget.git alias corpfidget > > It could then offer a CLI utility to issue a command like this using the > https API: > > vapor-git-thingy -g corpfidget -r 1234abcd..5678dcba -v2 -c coverletter.txt > > That would do the same as the above, plus do the patch generation > itself... > > Okay, I think I might be able to scrape up funding to get this built > once I put this into a more presentable form. That would be great! This could help solve a lot of e-mail issues that contributors have, but also I'm very interested in step 5 - the testing aspect. I would like to be involved in discussions of the design of that step, so we could plug lots of different tests in, at the request of various sub-system maintainers. I maintain the Fuego test system, so I'd be interested in making available our test suites for that step. Please let me know if there's some opportunity to follow up with you on this ( ie, a list where this might be discussed in more detail, or an event where we could talk face-to-face). Thanks, -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 18:58 ` Tim.Bird @ 2018-09-18 19:24 ` Konstantin Ryabitsev 0 siblings, 0 replies; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-18 19:24 UTC (permalink / raw) To: Tim.Bird; +Cc: James.Bottomley, mchehab+samsung, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 1973 bytes --] On Tue, Sep 18, 2018 at 06:58:45PM +0000, Tim.Bird@sony.com wrote: >> >> 1. Allows people to generate an account >> >> 2. Verifies their email address >> >> 3. Instructs people how to generate a patch or series of patches >> >> 4. Gives a way to upload generated patches >> >> 5. Runs checkpatch to make sure there are no errors >> >> 6. Runs get_maintainer to find out where the patch(es) should be sent to >> >> 7. (Does more imaginary magic, such as looking up message-id references) >> >> 8. Mails it out >This could help solve a lot of e-mail issues that contributors have, >but also >I'm very interested in step 5 - the testing aspect. I would like to be involved in >discussions of the design of that step, so we could plug lots of different tests >in, at the request of various sub-system maintainers. I maintain the Fuego >test system, so I'd be interested in making available our test suites for that >step. I'm not sure this is going to be the right tool for test-suite integration -- in fact, I'd argue that CI stuff should remain wholly outside of its scope. The goal is to make it easier to send good, acceptable patches (even if their content is no good). CI and any other automated testing should happen after these patches have hit LKML (and any other lists), if only because there is no One True Place That Does CI, and things like 0daybot/syzbot/etc are already honed to work via the mailing list. That said, I'm open to be convinced otherwise if others want this to happen *before* patches land on the mailing lists. If that is the case, we will want to rope kernelci folks into this discussion. >Please let me know if there's some opportunity to follow up with you on >this >( ie, a list where this might be discussed in more detail, or an event where we >could talk face-to-face). I'll be at the Kernel Summit in Vancouver, and I believe at least Kevin of KernelCI fame will be there, too. -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:31 ` Konstantin Ryabitsev 2018-09-18 17:42 ` Tim.Bird @ 2018-09-18 17:47 ` Geert Uytterhoeven 2018-09-18 17:49 ` Greg KH 2018-09-18 23:05 ` Laurent Pinchart 3 siblings, 0 replies; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-18 17:47 UTC (permalink / raw) To: Konstantin Ryabitsev Cc: James Bottomley, Mauro Carvalho Chehab, Bird, Timothy, ksummit-discuss [ To/Cc edited manually, Mail-Followup-To: seems to be weird ] On Tue, Sep 18, 2018 at 7:31 PM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: > On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote: > >> https://urldefense.proofpoint.com/v2/url?u=https- > >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing- > >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7- > >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y- > >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY- > >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e= > > Ick. Cool. And that URL actually works for me, even though wget truncated it. Can't see any damage in the actual result. But, is the service exploitable? > So, what if we imagine that there's an imaginary web tool that does > this: > > 1. Allows people to generate an account > 2. Verifies their email address > 3. Instructs people how to generate a patch or series of patches > 4. Gives a way to upload generated patches > 5. Runs checkpatch to make sure there are no errors > 6. Runs get_maintainer to find out where the patch(es) should be sent to > 7. (Does more imaginary magic, such as looking up message-id references) > 8. Mails it out > > Would that be useful or solve any problems? Or would that, on the > contrary, create more problems than it solves? Sounds useful. Perhaps even with github integration, so you can send a series with the work in your branch? Needs some serious safeguards, to prevent spamming everyone with e.g. the full patch series since v2.6.12-rc2. I'm actually surprised such an accident never happened so far with git send-email ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:31 ` Konstantin Ryabitsev 2018-09-18 17:42 ` Tim.Bird 2018-09-18 17:47 ` Geert Uytterhoeven @ 2018-09-18 17:49 ` Greg KH 2018-09-18 18:03 ` Konstantin Ryabitsev ` (2 more replies) 2018-09-18 23:05 ` Laurent Pinchart 3 siblings, 3 replies; 162+ messages in thread From: Greg KH @ 2018-09-18 17:49 UTC (permalink / raw) To: Tim.Bird, James.Bottomley, ksummit-discuss, mchehab+samsung On Tue, Sep 18, 2018 at 01:31:48PM -0400, Konstantin Ryabitsev wrote: > So, what if we imagine that there's an imaginary web tool that does this: > > 1. Allows people to generate an account > 2. Verifies their email address > 3. Instructs people how to generate a patch or series of patches > 4. Gives a way to upload generated patches > 5. Runs checkpatch to make sure there are no errors > 6. Runs get_maintainer to find out where the patch(es) should be sent to > 7. (Does more imaginary magic, such as looking up message-id references) > 8. Mails it out That last step might be hard, you have to "mail it out" to look like it came from the original author, right? Then all crud breaks out as you can't deliver an email from "sony.com" successfully. So you just provide them with a FOO1234@k.o account or some such munging, to reflect back to their original email address, but what happens when I ask for a change? Are you now a "man in the middle" forwarding emails around everywhere? That could get messy quickly. It's that feedback loop where things break down. I only accept on average, 1/3 of the patches sent to me, so retrys are a part of life, as is a conversation about what went wrong to deserve a retry. If you can incorporate that, great, we just invented gerrit! :) Seriously, it would be good, but no gerrit please... greg k-h ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:49 ` Greg KH @ 2018-09-18 18:03 ` Konstantin Ryabitsev 2018-09-18 22:46 ` Alexandre Belloni 2018-09-18 18:22 ` Dmitry Torokhov 2018-09-18 18:56 ` Sasha Levin 2 siblings, 1 reply; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-18 18:03 UTC (permalink / raw) To: Greg KH; +Cc: James.Bottomley, mchehab+samsung, Tim.Bird, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 1666 bytes --] On Tue, Sep 18, 2018 at 07:49:13PM +0200, Greg KH wrote: >> 1. Allows people to generate an account >> 2. Verifies their email address >> 3. Instructs people how to generate a patch or series of patches >> 4. Gives a way to upload generated patches >> 5. Runs checkpatch to make sure there are no errors >> 6. Runs get_maintainer to find out where the patch(es) should be sent to >> 7. (Does more imaginary magic, such as looking up message-id references) >> 8. Mails it out > >That last step might be hard, you have to "mail it out" to look like it >came from the original author, right? Then all crud breaks out as you >can't deliver an email from "sony.com" successfully. We already do nasty things to work around this. E.g. if you look at the envelope-sender for mail delivered via mail.kernel.org you'll see that it all looks like this: SRS0=crc=stuff=orig-domain.com=orig-local@kernel.org So, mailing it out and having it pass DKIM/SPF checks to be reliably delivered is something we can do. Or, we can send it from "vapor-git-thingy@kernel.org" and put the original sender into Reply-To, which is also kosher. >So you just provide them with a FOO1234@k.o account or some such >munging, to reflect back to their original email address, but what >happens when I ask for a change? Are you now a "man in the middle" >forwarding emails around everywhere? That could get messy quickly. It a reality we already live in, so it's not like we'd be exposing ourselves to anything we aren't exposed to as it is. >Seriously, it would be good, but no gerrit please... We'll call it ging for "ging is not gerrit". :) -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 18:03 ` Konstantin Ryabitsev @ 2018-09-18 22:46 ` Alexandre Belloni 0 siblings, 0 replies; 162+ messages in thread From: Alexandre Belloni @ 2018-09-18 22:46 UTC (permalink / raw) To: Greg KH, Tim.Bird, James.Bottomley, ksummit-discuss, mchehab+samsung On 18/09/2018 14:03:24-0400, Konstantin Ryabitsev wrote: > On Tue, Sep 18, 2018 at 07:49:13PM +0200, Greg KH wrote: > > > 1. Allows people to generate an account > > > 2. Verifies their email address > > > 3. Instructs people how to generate a patch or series of patches > > > 4. Gives a way to upload generated patches > > > 5. Runs checkpatch to make sure there are no errors > > > 6. Runs get_maintainer to find out where the patch(es) should be sent to > > > 7. (Does more imaginary magic, such as looking up message-id references) > > > 8. Mails it out > > > > That last step might be hard, you have to "mail it out" to look like it > > came from the original author, right? Then all crud breaks out as you > > can't deliver an email from "sony.com" successfully. > > We already do nasty things to work around this. E.g. if you look at the > envelope-sender for mail delivered via mail.kernel.org you'll see that it > all looks like this: SRS0=crc=stuff=orig-domain.com=orig-local@kernel.org > > So, mailing it out and having it pass DKIM/SPF checks to be reliably > delivered is something we can do. Or, we can send it from > "vapor-git-thingy@kernel.org" and put the original sender into Reply-To, > which is also kosher. > Wouldn't that break patchwork? I remember having to edit patches because it changed the name of the author to its previous named based on the email address (the name changed but not the email). Else, I find that a generally good idea. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:49 ` Greg KH 2018-09-18 18:03 ` Konstantin Ryabitsev @ 2018-09-18 18:22 ` Dmitry Torokhov 2018-09-18 19:16 ` Theodore Y. Ts'o 2018-09-18 18:56 ` Sasha Levin 2 siblings, 1 reply; 162+ messages in thread From: Dmitry Torokhov @ 2018-09-18 18:22 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: James Bottomley, Mauro Carvalho Chehab, Tim.Bird, ksummit-discuss On Tue, Sep 18, 2018 at 10:49 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Sep 18, 2018 at 01:31:48PM -0400, Konstantin Ryabitsev wrote: > > So, what if we imagine that there's an imaginary web tool that does this: > > > > 1. Allows people to generate an account > > 2. Verifies their email address > > 3. Instructs people how to generate a patch or series of patches > > 4. Gives a way to upload generated patches > > 5. Runs checkpatch to make sure there are no errors > > 6. Runs get_maintainer to find out where the patch(es) should be sent to > > 7. (Does more imaginary magic, such as looking up message-id references) > > 8. Mails it out > > That last step might be hard, you have to "mail it out" to look like it > came from the original author, right? Then all crud breaks out as you > can't deliver an email from "sony.com" successfully. > > So you just provide them with a FOO1234@k.o account or some such > munging, to reflect back to their original email address, but what > happens when I ask for a change? Are you now a "man in the middle" > forwarding emails around everywhere? That could get messy quickly. > > It's that feedback loop where things break down. I only accept on > average, 1/3 of the patches sent to me, so retrys are a part of life, as > is a conversation about what went wrong to deserve a retry. > > If you can incorporate that, great, we just invented gerrit! :) > > Seriously, it would be good, but no gerrit please... Seconded. I swear 75% of time I spend on patch reviews that I do for Chrome OS is spent on clicking around UI, not actually commenting on the issues I find. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 18:22 ` Dmitry Torokhov @ 2018-09-18 19:16 ` Theodore Y. Ts'o 0 siblings, 0 replies; 162+ messages in thread From: Theodore Y. Ts'o @ 2018-09-18 19:16 UTC (permalink / raw) To: Dmitry Torokhov Cc: James Bottomley, Greg Kroah-Hartman, Tim.Bird, ksummit-discuss, Mauro Carvalho Chehab On Tue, Sep 18, 2018 at 11:22:15AM -0700, Dmitry Torokhov wrote: > > Seriously, it would be good, but no gerrit please... > > Seconded. I swear 75% of time I spend on patch reviews that I do for > Chrome OS is spent on clicking around UI, not actually commenting on > the issues I find. Heh. I don't know if I'm an outlier, but I actually *like* Gerrit. (I use it at work for reviewing changes to Google's data center, Chrome OS, and Android kernels.) For small changes, being able to directly see the context of a change via the web UI is really nice. Also being able to make a comment in-line where the change is, and then seeing the replies chained off of it, right next to the code, is also really nice. I also really like being able to trivially look at differences between the -v3 and -v5 version of the commit via the web UI. It doesn't work as well for large patch series, certainly. For that what I tend to do is to download the branch from gerrit into the my local git repo, and look at all of the changes using standard git tools (e.g., git grep, git blame, etc.) So while Gerrit does have some shortcomings, it definitely does have some things that it does do very well. For large patch series and for the sort of things that I need to deal with for upstream development, I still use e-mail a lot, obviously. But if we're talking about the platonic ideal of large-scale distributed development, we shouldn't dismiss all of Gerrit's functionality out of hand. Cheers, - Ted ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:49 ` Greg KH 2018-09-18 18:03 ` Konstantin Ryabitsev 2018-09-18 18:22 ` Dmitry Torokhov @ 2018-09-18 18:56 ` Sasha Levin 2 siblings, 0 replies; 162+ messages in thread From: Sasha Levin @ 2018-09-18 18:56 UTC (permalink / raw) To: Greg KH; +Cc: James.Bottomley, mchehab+samsung, Tim.Bird, ksummit-discuss On Tue, Sep 18, 2018 at 07:49:13PM +0200, Greg KH wrote: >On Tue, Sep 18, 2018 at 01:31:48PM -0400, Konstantin Ryabitsev wrote: >> So, what if we imagine that there's an imaginary web tool that does this: >> >> 1. Allows people to generate an account >> 2. Verifies their email address >> 3. Instructs people how to generate a patch or series of patches >> 4. Gives a way to upload generated patches >> 5. Runs checkpatch to make sure there are no errors >> 6. Runs get_maintainer to find out where the patch(es) should be sent to >> 7. (Does more imaginary magic, such as looking up message-id references) >> 8. Mails it out > >That last step might be hard, you have to "mail it out" to look like it >came from the original author, right? Then all crud breaks out as you >can't deliver an email from "sony.com" successfully. Why do we need to make it look like it came from the original author? If we include a "From:" field in the patch then git will do the right thing, and if we just Cc the original author then any questions/reviews/comments will be directed to the author without going through this system. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:31 ` Konstantin Ryabitsev ` (2 preceding siblings ...) 2018-09-18 17:49 ` Greg KH @ 2018-09-18 23:05 ` Laurent Pinchart 3 siblings, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-18 23:05 UTC (permalink / raw) To: ksummit-discuss Cc: James.Bottomley, mchehab+samsung, Tim.Bird, Konstantin Ryabitsev Hi Konstantin, On Tuesday, 18 September 2018 20:31:48 EEST Konstantin Ryabitsev wrote: > On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote: > >> https://urldefense.proofpoint.com/v2/url?u=https-> >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing- > >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7- > >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y- > >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY- > >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e= > > Ick. > > > Thank you for the offer. However, while that's a solution that might > > work for me (modulo my ability to punch my way through the firewall to > > that mail server), it doesn't scale or help my colleagues at Sony who I'm > > trying to remove barriers for as well. I'm senior enough at Sony to have > > a somewhat different situation than other Sony Linux developers, however > > I intentionally work through the IT department and use commonly provided > > tools here in order to 1) understand the hurdles other developers at Sony > > have, and 2) work on general solutions. > > Ah, I understand your situation better now. > > So, what if we imagine that there's an imaginary web tool that does > this: > > 1. Allows people to generate an account > 2. Verifies their email address > 3. Instructs people how to generate a patch or series of patches > 4. Gives a way to upload generated patches > 5. Runs checkpatch to make sure there are no errors > 6. Runs get_maintainer to find out where the patch(es) should be sent to > 7. (Does more imaginary magic, such as looking up message-id references) > 8. Mails it out > > Would that be useful or solve any problems? Or would that, on the > contrary, create more problems than it solves? What if that imaginary web tool accepted a git push fo steps 3 and 4 ? It would be nice if the git push could be unauthenticated, but I understand that could cause spam and other related issues. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 22:39 ` Dave Airlie 2018-09-17 23:04 ` James Bottomley @ 2018-09-18 7:37 ` Nicolas Ferre 2018-09-18 7:47 ` Geert Uytterhoeven 2018-09-18 10:38 ` Laurent Pinchart 2 siblings, 1 reply; 162+ messages in thread From: Nicolas Ferre @ 2018-09-18 7:37 UTC (permalink / raw) To: Dave Airlie, mchehab+samsung; +Cc: ksummit On 18/09/2018 at 00:39, Dave Airlie wrote: >> This is a valid point: whatever development process is used, drive-by >> contributors should be allowed to send e-mails without needing to subscribe >> (neither to a moderated list nor to a web-UI). I don't care how the >> maintainer will handle such patches, provided that they will be properly >> handled. >> > It really depends on what type of one-off contributor they are. > > Setting up git send-email isn't trivial for everyone, if you are a > gmail user and work for a company that doesn't embrace smtp so much, Indeed, an always recommencing uphill battle of Open Source group of engineers in an "Enterprise" environment... > then having a webui and https git access will be a lot easier for > one-off contributions. > > Beware of thinking our setup with email is in any way simple for a > newcomer to setup properly. > > Dave. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > -- Nicolas Ferre ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 7:37 ` Nicolas Ferre @ 2018-09-18 7:47 ` Geert Uytterhoeven 0 siblings, 0 replies; 162+ messages in thread From: Geert Uytterhoeven @ 2018-09-18 7:47 UTC (permalink / raw) To: Nicolas Ferre; +Cc: Mauro Carvalho Chehab, ksummit-discuss On Tue, Sep 18, 2018 at 9:37 AM Nicolas Ferre <nicolas.ferre@microchip.com> wrote: > On 18/09/2018 at 00:39, Dave Airlie wrote: > >> This is a valid point: whatever development process is used, drive-by > >> contributors should be allowed to send e-mails without needing to subscribe > >> (neither to a moderated list nor to a web-UI). I don't care how the > >> maintainer will handle such patches, provided that they will be properly > >> handled. > >> > > It really depends on what type of one-off contributor they are. > > > > Setting up git send-email isn't trivial for everyone, if you are a > > gmail user and work for a company that doesn't embrace smtp so much, > > Indeed, an always recommencing uphill battle of Open Source group of > engineers in an "Enterprise" environment... This is not limited to Open Source cooperation. When people from multiple companies are working together in other areas, it is not uncommon for some of them to be blocked from access to collaboration tools in the same "Enterprise" environment. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 22:39 ` Dave Airlie 2018-09-17 23:04 ` James Bottomley 2018-09-18 7:37 ` Nicolas Ferre @ 2018-09-18 10:38 ` Laurent Pinchart 2018-09-18 16:02 ` Mark Brown 2 siblings, 1 reply; 162+ messages in thread From: Laurent Pinchart @ 2018-09-18 10:38 UTC (permalink / raw) To: Dave Airlie; +Cc: mchehab+samsung, ksummit On Tuesday, 18 September 2018 01:39:48 EEST Dave Airlie wrote: > > This is a valid point: whatever development process is used, drive-by > > contributors should be allowed to send e-mails without needing to > > subscribe > > (neither to a moderated list nor to a web-UI). I don't care how the > > maintainer will handle such patches, provided that they will be properly > > handled. > > It really depends on what type of one-off contributor they are. > > Setting up git send-email isn't trivial for everyone, if you are a > gmail user and work for a company that doesn't embrace smtp so much, > then having a webui and https git access will be a lot easier for > one-off contributions. > > Beware of thinking our setup with email is in any way simple for a > newcomer to setup properly. Would there be some value in creating new git-send-gmail or git-send-outlook scripts that would work around the issues with common mail providers ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 10:38 ` Laurent Pinchart @ 2018-09-18 16:02 ` Mark Brown 2018-09-18 16:32 ` Luck, Tony 2018-09-18 16:50 ` David Woodhouse 0 siblings, 2 replies; 162+ messages in thread From: Mark Brown @ 2018-09-18 16:02 UTC (permalink / raw) To: Laurent Pinchart; +Cc: mchehab+samsung, Tim Bird, ksummit [-- Attachment #1: Type: text/plain, Size: 853 bytes --] On Tue, Sep 18, 2018 at 01:38:09PM +0300, Laurent Pinchart wrote: > Would there be some value in creating new git-send-gmail or git-send-outlook > scripts that would work around the issues with common mail providers ? At least with Outlook the problem is partly that Outlook's model of how e-mail works isn't really able to cope with what we need, it translates everything into internal formats in a way that is at best fragile for what we need. A while ago Tim Bird (CCed) had the idea to release a VM image which sysadmins could easily deploy inside a company providing services that'd be needed to interact with the community - things like a mechanism to send and recieve e-mail. The theory was that something that was nicely packaged, documented and auditable would be more approachable for corporate admins who aren't experts. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:02 ` Mark Brown @ 2018-09-18 16:32 ` Luck, Tony 2018-09-18 16:35 ` Dmitry Torokhov ` (2 more replies) 2018-09-18 16:50 ` David Woodhouse 1 sibling, 3 replies; 162+ messages in thread From: Luck, Tony @ 2018-09-18 16:32 UTC (permalink / raw) To: Mark Brown; +Cc: mchehab+samsung, Tim Bird, ksummit On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > At least with Outlook the problem is partly that Outlook's model of how > e-mail works isn't really able to cope with what we need, it translates > everything into internal formats in a way that is at best fragile for > what we need. Or, shock, horror, tell one-time contributors that it is OK to put the patch in an attachment to the e-mail. Outlook doesn't (usually) mess with the contents of attachments. -Tony ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:32 ` Luck, Tony @ 2018-09-18 16:35 ` Dmitry Torokhov 2018-09-18 17:18 ` Linus Torvalds ` (3 more replies) 2018-09-18 17:10 ` Tim.Bird 2018-09-18 20:48 ` Takashi Iwai 2 siblings, 4 replies; 162+ messages in thread From: Dmitry Torokhov @ 2018-09-18 16:35 UTC (permalink / raw) To: Luck, Tony; +Cc: Mauro Carvalho Chehab, tim.bird, ksummit-discuss On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > > At least with Outlook the problem is partly that Outlook's model of how > > e-mail works isn't really able to cope with what we need, it translates > > everything into internal formats in a way that is at best fragile for > > what we need. > > Or, shock, horror, tell one-time contributors that it is OK to > put the patch in an attachment to the e-mail. Outlook doesn't > (usually) mess with the contents of attachments. And then have maintainer having hard time trying to comment on said patch in the attachment. I'd rather not. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:35 ` Dmitry Torokhov @ 2018-09-18 17:18 ` Linus Torvalds 2018-09-18 17:28 ` Sean Paul ` (2 more replies) 2018-09-18 17:21 ` Mark Brown ` (2 subsequent siblings) 3 siblings, 3 replies; 162+ messages in thread From: Linus Torvalds @ 2018-09-18 17:18 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: mchehab+samsung, tim.bird, ksummit [ Still very much on break, but reading ksuummit-discuss and answering this one ] On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > > > > Or, shock, horror, tell one-time contributors that it is OK to > > put the patch in an attachment to the e-mail. Outlook doesn't > > (usually) mess with the contents of attachments. > > And then have maintainer having hard time trying to comment on said > patch in the attachment. I'd rather not. I actually think that *this* could be easily handled by trivial tooling that doesn't have to be set up over and over again inside companies or teaching people. In fact, doesn't patchwork already do exactly that? I have to say, there are real technical advantages to using attachments for patches, particularly when you have odd combinations of locales. It's gotten to be less of an issue over time and we're still almost entirely US-ASCII with the occasional UTF-8, but we do still have the occasional problem. Using attachments at least detaches the email charset from the user locale, and from random other MUA issues. But yes, the "comment on individual parts of the patch" part is very important too. The main problem with having something that rewrites things is that it breaks DKIM etc, so you can't just have a pure email gateway. It almost needs to be something at a higher semantic level like patchwork (that could still send out rewritten emails). In many cases, you might want that anyway (ie wouldn't it be lovely when the patch is also checked for "does it build" and looks up the maintainers based on what paths it touches etc etc). So a sane email / web-interface kind of gateway that allows people to work the way they prefer. But I guess "trivial" is completely the wrong word to use. Linus ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:18 ` Linus Torvalds @ 2018-09-18 17:28 ` Sean Paul 2018-09-18 17:37 ` Tim.Bird 2018-09-21 16:46 ` Olof Johansson 2 siblings, 0 replies; 162+ messages in thread From: Sean Paul @ 2018-09-18 17:28 UTC (permalink / raw) To: Linus Torvalds; +Cc: mchehab+samsung, tim.bird, ksummit On Tue, Sep 18, 2018 at 10:18:25AM -0700, Linus Torvalds wrote: > [ Still very much on break, but reading ksuummit-discuss and answering > this one ] > > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > > > > > > Or, shock, horror, tell one-time contributors that it is OK to > > > put the patch in an attachment to the e-mail. Outlook doesn't > > > (usually) mess with the contents of attachments. > > > > And then have maintainer having hard time trying to comment on said > > patch in the attachment. I'd rather not. > > I actually think that *this* could be easily handled by trivial > tooling that doesn't have to be set up over and over again inside > companies or teaching people. > > In fact, doesn't patchwork already do exactly that? > > I have to say, there are real technical advantages to using > attachments for patches, particularly when you have odd combinations > of locales. It's gotten to be less of an issue over time and we're > still almost entirely US-ASCII with the occasional UTF-8, but we do > still have the occasional problem. Using attachments at least detaches > the email charset from the user locale, and from random other MUA > issues. > > But yes, the "comment on individual parts of the patch" part is very > important too. > > The main problem with having something that rewrites things is that it > breaks DKIM etc, so you can't just have a pure email gateway. Worse yet is that the failures are silent. We had DMARC helpfully enabled on chromium.org for 3 weeks and my mail was going to Spam folders without me knowing. Sean > It > almost needs to be something at a higher semantic level like patchwork > (that could still send out rewritten emails). > > In many cases, you might want that anyway (ie wouldn't it be lovely > when the patch is also checked for "does it build" and looks up the > maintainers based on what paths it touches etc etc). > > So a sane email / web-interface kind of gateway that allows people to > work the way they prefer. > > But I guess "trivial" is completely the wrong word to use. > > Linus > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Sean Paul, Software Engineer, Google / Chromium OS ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:18 ` Linus Torvalds 2018-09-18 17:28 ` Sean Paul @ 2018-09-18 17:37 ` Tim.Bird 2018-09-21 16:46 ` Olof Johansson 2 siblings, 0 replies; 162+ messages in thread From: Tim.Bird @ 2018-09-18 17:37 UTC (permalink / raw) To: torvalds, dmitry.torokhov; +Cc: mchehab+samsung, ksummit-discuss > -----Original Message----- > From: Linus Torvalds > > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > > > > > > Or, shock, horror, tell one-time contributors that it is OK to > > > put the patch in an attachment to the e-mail. Outlook doesn't > > > (usually) mess with the contents of attachments. > > > > And then have maintainer having hard time trying to comment on said > > patch in the attachment. I'd rather not. > > I actually think that *this* could be easily handled by trivial > tooling that doesn't have to be set up over and over again inside > companies or teaching people. > > In fact, doesn't patchwork already do exactly that? > > I have to say, there are real technical advantages to using > attachments for patches, particularly when you have odd combinations > of locales. It's gotten to be less of an issue over time and we're > still almost entirely US-ASCII with the occasional UTF-8, but we do > still have the occasional problem. Using attachments at least detaches > the email charset from the user locale, and from random other MUA > issues. > > But yes, the "comment on individual parts of the patch" part is very > important too. > > The main problem with having something that rewrites things is that it > breaks DKIM etc, so you can't just have a pure email gateway. It > almost needs to be something at a higher semantic level like patchwork > (that could still send out rewritten emails). > > In many cases, you might want that anyway (ie wouldn't it be lovely > when the patch is also checked for "does it build" and looks up the > maintainers based on what paths it touches etc etc). > > So a sane email / web-interface kind of gateway that allows people to > work the way they prefer. Would it suffice to have some front-end e-mail receiver, listed in MAINTAINERS even, where patches were sent to, that did patch processing (including CI stuff) before sending it on to the "official" list? It could also automatically send responses to submitters with things to fix. That would be good for both the senders and the receivers. I'm not that familiar with 0day, but it does some of this now, right, but without the separate e-mail address? The benefit of putting together this kind of gateway is that it clearly delineates where the automatic patch pre-processing will occur, and different sub-systems could opt in or out of individual checks by the service. -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:18 ` Linus Torvalds 2018-09-18 17:28 ` Sean Paul 2018-09-18 17:37 ` Tim.Bird @ 2018-09-21 16:46 ` Olof Johansson 2018-09-21 17:08 ` Mauro Carvalho Chehab 2 siblings, 1 reply; 162+ messages in thread From: Olof Johansson @ 2018-09-21 16:46 UTC (permalink / raw) To: Linus Torvalds; +Cc: mchehab+samsung, tim.bird, ksummit On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > [ Still very much on break, but reading ksuummit-discuss and answering > this one ] > > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: >> > >> > Or, shock, horror, tell one-time contributors that it is OK to >> > put the patch in an attachment to the e-mail. Outlook doesn't >> > (usually) mess with the contents of attachments. >> >> And then have maintainer having hard time trying to comment on said >> patch in the attachment. I'd rather not. > > I actually think that *this* could be easily handled by trivial > tooling that doesn't have to be set up over and over again inside > companies or teaching people. > > In fact, doesn't patchwork already do exactly that? > > I have to say, there are real technical advantages to using > attachments for patches, particularly when you have odd combinations > of locales. It's gotten to be less of an issue over time and we're > still almost entirely US-ASCII with the occasional UTF-8, but we do > still have the occasional problem. Using attachments at least detaches > the email charset from the user locale, and from random other MUA > issues. > > But yes, the "comment on individual parts of the patch" part is very > important too. > > The main problem with having something that rewrites things is that it > breaks DKIM etc, so you can't just have a pure email gateway. It > almost needs to be something at a higher semantic level like patchwork > (that could still send out rewritten emails). > > In many cases, you might want that anyway (ie wouldn't it be lovely > when the patch is also checked for "does it build" and looks up the > maintainers based on what paths it touches etc etc). > > So a sane email / web-interface kind of gateway that allows people to > work the way they prefer. > > But I guess "trivial" is completely the wrong word to use. We're already starting to use some bots that sit on the mailing lists and monitor incoming material. This could be solved with something as simple as a bot that takes the patch-as-attachment, does a few useful things like runs checkpatch and makes sure it applies cleanly (maybe report what trees it applies cleanly to, such as current mainline and next), and then inlines the whole patch. All as a reply-all to the sender + original recipients. That way, anyone looking to do an inline review can do it on the bot version, and the originator will still receive the feedback, etc. It'd also solve the DKIM-related aspects, if I'm not mistaken. People who get distracted by the bot emails can easily choose to filter it. -Olof ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-21 16:46 ` Olof Johansson @ 2018-09-21 17:08 ` Mauro Carvalho Chehab 2018-09-21 17:16 ` Olof Johansson 0 siblings, 1 reply; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-21 17:08 UTC (permalink / raw) To: Olof Johansson; +Cc: tim.bird, ksummit Em Fri, 21 Sep 2018 17:46:13 +0100 Olof Johansson <olof@lixom.net> escreveu: > On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > [ Still very much on break, but reading ksuummit-discuss and answering > > this one ] > > > > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov > > <dmitry.torokhov@gmail.com> wrote: > >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > >> > > >> > Or, shock, horror, tell one-time contributors that it is OK to > >> > put the patch in an attachment to the e-mail. Outlook doesn't > >> > (usually) mess with the contents of attachments. > >> > >> And then have maintainer having hard time trying to comment on said > >> patch in the attachment. I'd rather not. > > > > I actually think that *this* could be easily handled by trivial > > tooling that doesn't have to be set up over and over again inside > > companies or teaching people. > > > > In fact, doesn't patchwork already do exactly that? > > > > I have to say, there are real technical advantages to using > > attachments for patches, particularly when you have odd combinations > > of locales. It's gotten to be less of an issue over time and we're > > still almost entirely US-ASCII with the occasional UTF-8, but we do > > still have the occasional problem. Using attachments at least detaches > > the email charset from the user locale, and from random other MUA > > issues. > > > > But yes, the "comment on individual parts of the patch" part is very > > important too. > > > > The main problem with having something that rewrites things is that it > > breaks DKIM etc, so you can't just have a pure email gateway. It > > almost needs to be something at a higher semantic level like patchwork > > (that could still send out rewritten emails). > > > > In many cases, you might want that anyway (ie wouldn't it be lovely > > when the patch is also checked for "does it build" and looks up the > > maintainers based on what paths it touches etc etc). > > > > So a sane email / web-interface kind of gateway that allows people to > > work the way they prefer. > > > > But I guess "trivial" is completely the wrong word to use. > > We're already starting to use some bots that sit on the mailing lists > and monitor incoming material. > > This could be solved with something as simple as a bot that takes the > patch-as-attachment, does a few useful things like runs checkpatch and > makes sure it applies cleanly (maybe report what trees it applies > cleanly to, such as current mainline and next), and then inlines the > whole patch. All as a reply-all to the sender + original recipients. > > That way, anyone looking to do an inline review can do it on the bot > version, and the originator will still receive the feedback, etc. It'd > also solve the DKIM-related aspects, if I'm not mistaken. > > People who get distracted by the bot emails can easily choose to filter it. Seems to work. Still, there are some issues with that. Depending on the email client, it may not recognize the patch as is, and use a wrong mime-type. If the mail server doesn't recognize the mime-type, or considers it evil, it may reject the e-mail, and the bot will get nothing. Not sure what's the current status of e-mailers and patches, but on my past experiences on another company (lots of years ago), usually webmail solutions are worse[1], and don't properly tag certain types of attachments. [1] I know places where only a corporate webmail solution is allowed by default, and using any other solution would require an special security approval. Not sure if is worth to consider such scenario, though. Another problem is that bots will receive the same e-mail twice (the original one and the inlined one). We may start having multiple kernel-test robots reply for such emails, with is not a good thing. So, if done this way, it is probably worth to add some meta-tags to avoid the new e-mail with the same patch to be parsed again by (other) robots. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-21 17:08 ` Mauro Carvalho Chehab @ 2018-09-21 17:16 ` Olof Johansson 0 siblings, 0 replies; 162+ messages in thread From: Olof Johansson @ 2018-09-21 17:16 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: tim.bird, ksummit On Fri, Sep 21, 2018 at 6:08 PM, Mauro Carvalho Chehab <mchehab@kernel.org> wrote: > Em Fri, 21 Sep 2018 17:46:13 +0100 > Olof Johansson <olof@lixom.net> escreveu: > >> On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >> > [ Still very much on break, but reading ksuummit-discuss and answering >> > this one ] >> > >> > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov >> > <dmitry.torokhov@gmail.com> wrote: >> >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: >> >> > >> >> > Or, shock, horror, tell one-time contributors that it is OK to >> >> > put the patch in an attachment to the e-mail. Outlook doesn't >> >> > (usually) mess with the contents of attachments. >> >> >> >> And then have maintainer having hard time trying to comment on said >> >> patch in the attachment. I'd rather not. >> > >> > I actually think that *this* could be easily handled by trivial >> > tooling that doesn't have to be set up over and over again inside >> > companies or teaching people. >> > >> > In fact, doesn't patchwork already do exactly that? >> > >> > I have to say, there are real technical advantages to using >> > attachments for patches, particularly when you have odd combinations >> > of locales. It's gotten to be less of an issue over time and we're >> > still almost entirely US-ASCII with the occasional UTF-8, but we do >> > still have the occasional problem. Using attachments at least detaches >> > the email charset from the user locale, and from random other MUA >> > issues. >> > >> > But yes, the "comment on individual parts of the patch" part is very >> > important too. >> > >> > The main problem with having something that rewrites things is that it >> > breaks DKIM etc, so you can't just have a pure email gateway. It >> > almost needs to be something at a higher semantic level like patchwork >> > (that could still send out rewritten emails). >> > >> > In many cases, you might want that anyway (ie wouldn't it be lovely >> > when the patch is also checked for "does it build" and looks up the >> > maintainers based on what paths it touches etc etc). >> > >> > So a sane email / web-interface kind of gateway that allows people to >> > work the way they prefer. >> > >> > But I guess "trivial" is completely the wrong word to use. >> >> We're already starting to use some bots that sit on the mailing lists >> and monitor incoming material. >> >> This could be solved with something as simple as a bot that takes the >> patch-as-attachment, does a few useful things like runs checkpatch and >> makes sure it applies cleanly (maybe report what trees it applies >> cleanly to, such as current mainline and next), and then inlines the >> whole patch. All as a reply-all to the sender + original recipients. >> >> That way, anyone looking to do an inline review can do it on the bot >> version, and the originator will still receive the feedback, etc. It'd >> also solve the DKIM-related aspects, if I'm not mistaken. >> >> People who get distracted by the bot emails can easily choose to filter it. > > Seems to work. > > Still, there are some issues with that. Depending on the email client, > it may not recognize the patch as is, and use a wrong mime-type. > If the mail server doesn't recognize the mime-type, or considers it > evil, it may reject the e-mail, and the bot will get nothing. > Not sure what's the current status of e-mailers and patches, but on > my past experiences on another company (lots of years ago), usually > webmail solutions are worse[1], and don't properly tag certain types > of attachments. > > [1] I know places where only a corporate webmail solution is allowed > by default, and using any other solution would require an special > security approval. Not sure if is worth to consider such scenario, > though. All of these sound like solvable problems to me, by having the bot be lenient about what it accepts. It might get a bit messy and might need tuning over time, but that's fine. > Another problem is that bots will receive the same e-mail twice > (the original one and the inlined one). We may start having > multiple kernel-test robots reply for such emails, with is not > a good thing. So, if done this way, it is probably worth to add > some meta-tags to avoid the new e-mail with the same patch > to be parsed again by (other) robots. With only a couple of active bots, making them filter each other would be a trivial initial approach. -Olof ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:35 ` Dmitry Torokhov 2018-09-18 17:18 ` Linus Torvalds @ 2018-09-18 17:21 ` Mark Brown 2018-09-18 21:01 ` Steven Rostedt 2018-09-19 9:46 ` James Bottomley 3 siblings, 0 replies; 162+ messages in thread From: Mark Brown @ 2018-09-18 17:21 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Mauro Carvalho Chehab, tim.bird, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 1162 bytes --] On Tue, Sep 18, 2018 at 09:35:28AM -0700, Dmitry Torokhov wrote: > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > > > At least with Outlook the problem is partly that Outlook's model of how > > > e-mail works isn't really able to cope with what we need, it translates > > > everything into internal formats in a way that is at best fragile for > > > what we need. > > Or, shock, horror, tell one-time contributors that it is OK to > > put the patch in an attachment to the e-mail. Outlook doesn't > > (usually) mess with the contents of attachments. > And then have maintainer having hard time trying to comment on said > patch in the attachment. I'd rather not. Right, that can be an issue - things usually make it through without modification which is good but depending on the e-mail client it can be a pain to review, especially if the patch ends up not being given a text MIME type. It is doable but it's not great. It also doesn't scale well in cases where it's a company that's actively engaging and sending a lot of stuff and participating in discussions. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:35 ` Dmitry Torokhov 2018-09-18 17:18 ` Linus Torvalds 2018-09-18 17:21 ` Mark Brown @ 2018-09-18 21:01 ` Steven Rostedt 2018-09-18 23:16 ` Laurent Pinchart 2018-09-18 23:54 ` Mark Brown 2018-09-19 9:46 ` James Bottomley 3 siblings, 2 replies; 162+ messages in thread From: Steven Rostedt @ 2018-09-18 21:01 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Mauro Carvalho Chehab, tim.bird, ksummit-discuss On Tue, 18 Sep 2018 09:35:28 -0700 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote: > > > > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > > > At least with Outlook the problem is partly that Outlook's model of how > > > e-mail works isn't really able to cope with what we need, it translates > > > everything into internal formats in a way that is at best fragile for > > > what we need. > > > > Or, shock, horror, tell one-time contributors that it is OK to > > put the patch in an attachment to the e-mail. Outlook doesn't > > (usually) mess with the contents of attachments. > > And then have maintainer having hard time trying to comment on said > patch in the attachment. I'd rather not. > This is why I use claws-mail. One of the nice features to it, is if you receive a patch as an attachment, you open it up, select all the text (right-click->select all), and then hit "reply". It makes it just as if the patch was the email. Then you can easily make your inline comments as usual. -- Steve ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 21:01 ` Steven Rostedt @ 2018-09-18 23:16 ` Laurent Pinchart 2018-09-18 23:54 ` Mark Brown 1 sibling, 0 replies; 162+ messages in thread From: Laurent Pinchart @ 2018-09-18 23:16 UTC (permalink / raw) To: ksummit-discuss; +Cc: Mauro Carvalho Chehab, tim.bird On Wednesday, 19 September 2018 00:01:47 EEST Steven Rostedt wrote: > On Tue, 18 Sep 2018 09:35:28 -0700 Dmitry Torokhov wrote: > > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony wrote: > >> On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > >>> At least with Outlook the problem is partly that Outlook's model of > >>> how e-mail works isn't really able to cope with what we need, it > >>> translates everything into internal formats in a way that is at best > >>> fragile for what we need. > >> > >> Or, shock, horror, tell one-time contributors that it is OK to > >> put the patch in an attachment to the e-mail. Outlook doesn't > >> (usually) mess with the contents of attachments. > > > > And then have maintainer having hard time trying to comment on said > > patch in the attachment. I'd rather not. > > This is why I use claws-mail. One of the nice features to it, is if you > receive a patch as an attachment, you open it up, select all the text > (right-click->select all), and then hit "reply". It makes it just as if > the patch was the email. Then you can easily make your inline comments > as usual. I wouldn't mind patches sent as attachments if I could just hit a reply-as- inline shortcut that would take all attachments and properly inline them, quoting the result and opening the reply window. That should be fairly easy to implement in <insert-mail-client-here> but more difficult if we wanted to patch all popular (and less popular) mail clients. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 21:01 ` Steven Rostedt 2018-09-18 23:16 ` Laurent Pinchart @ 2018-09-18 23:54 ` Mark Brown 2018-09-19 5:27 ` Christoph Hellwig 1 sibling, 1 reply; 162+ messages in thread From: Mark Brown @ 2018-09-18 23:54 UTC (permalink / raw) To: Steven Rostedt; +Cc: Mauro Carvalho Chehab, tim.bird, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 656 bytes --] On Tue, Sep 18, 2018 at 05:01:47PM -0400, Steven Rostedt wrote: > This is why I use claws-mail. One of the nice features to it, is if you > receive a patch as an attachment, you open it up, select all the text > (right-click->select all), and then hit "reply". It makes it just as if > the patch was the email. Then you can easily make your inline comments > as usual. mutt's even nicer here, if the attachment has a text MIME type it'l just include it in the reply (possibly this is configurable but it's what I want and it does it by default for me). This does get broken if the sender flags the message with a non-text type for some reason though :( [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 23:54 ` Mark Brown @ 2018-09-19 5:27 ` Christoph Hellwig 0 siblings, 0 replies; 162+ messages in thread From: Christoph Hellwig @ 2018-09-19 5:27 UTC (permalink / raw) To: Mark Brown; +Cc: Mauro Carvalho Chehab, tim.bird, ksummit-discuss On Tue, Sep 18, 2018 at 04:54:12PM -0700, Mark Brown wrote: > > This is why I use claws-mail. One of the nice features to it, is if you > > receive a patch as an attachment, you open it up, select all the text > > (right-click->select all), and then hit "reply". It makes it just as if > > the patch was the email. Then you can easily make your inline comments > > as usual. > > mutt's even nicer here, if the attachment has a text MIME type it'l just > include it in the reply (possibly this is configurable but it's what I > want and it does it by default for me). This does get broken if the > sender flags the message with a non-text type for some reason though :( I was just going to say that I rarely had problems with attached patched recently as mutt seems to handle them right in replies transparently. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:35 ` Dmitry Torokhov ` (2 preceding siblings ...) 2018-09-18 21:01 ` Steven Rostedt @ 2018-09-19 9:46 ` James Bottomley 3 siblings, 0 replies; 162+ messages in thread From: James Bottomley @ 2018-09-19 9:46 UTC (permalink / raw) To: Dmitry Torokhov, Luck, Tony Cc: Mauro Carvalho Chehab, tim.bird, ksummit-discuss On Tue, 2018-09-18 at 09:35 -0700, Dmitry Torokhov wrote: > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> > wrote: > > > > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > > > At least with Outlook the problem is partly that Outlook's model > > > of how > > > e-mail works isn't really able to cope with what we need, it > > > translates > > > everything into internal formats in a way that is at best fragile > > > for > > > what we need. > > > > Or, shock, horror, tell one-time contributors that it is OK to > > put the patch in an attachment to the e-mail. Outlook doesn't > > (usually) mess with the contents of attachments. > > And then have maintainer having hard time trying to comment on said > patch in the attachment. I'd rather not. We've long accepted attached patches from exchange people in SCSI (usually we request them when the whitespace damage can't be fixed any other way). It's a pain to reply to because you have to cut and paste from the attachment in the reply but it's not impossible and if it's the only way to get the patch out of the corporation in the first place, I think the pain is acceptable. James ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:32 ` Luck, Tony 2018-09-18 16:35 ` Dmitry Torokhov @ 2018-09-18 17:10 ` Tim.Bird 2018-09-18 20:48 ` Takashi Iwai 2 siblings, 0 replies; 162+ messages in thread From: Tim.Bird @ 2018-09-18 17:10 UTC (permalink / raw) To: tony.luck, broonie; +Cc: mchehab+samsung, ksummit-discuss > -----Original Message----- > From: Luck, Tony > > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > > At least with Outlook the problem is partly that Outlook's model of how > > e-mail works isn't really able to cope with what we need, it translates > > everything into internal formats in a way that is at best fragile for > > what we need. > > Or, shock, horror, tell one-time contributors that it is OK to > put the patch in an attachment to the e-mail. Outlook doesn't > (usually) mess with the contents of attachments. That is what I do on my testing project. It might be nice to have the mail list software detect an attached text file, and incorporate it into the body so reviews could be done in the standard fashion, or to have git am detect attached messages. -- Tim ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:32 ` Luck, Tony 2018-09-18 16:35 ` Dmitry Torokhov 2018-09-18 17:10 ` Tim.Bird @ 2018-09-18 20:48 ` Takashi Iwai 2 siblings, 0 replies; 162+ messages in thread From: Takashi Iwai @ 2018-09-18 20:48 UTC (permalink / raw) To: Luck, Tony; +Cc: mchehab+samsung, Tim Bird, ksummit On Tue, 18 Sep 2018 18:32:34 +0200, Luck, Tony wrote: > > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote: > > At least with Outlook the problem is partly that Outlook's model of how > > e-mail works isn't really able to cope with what we need, it translates > > everything into internal formats in a way that is at best fragile for > > what we need. > > Or, shock, horror, tell one-time contributors that it is OK to > put the patch in an attachment to the e-mail. Outlook doesn't > (usually) mess with the contents of attachments. Yeah, that's what I usually ask as the last resort if anything else can't help. It's a bit of pain to expand the attachment in the reply, but, hey, I'm using Emacs, the great OS itself :) Takashi ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:02 ` Mark Brown 2018-09-18 16:32 ` Luck, Tony @ 2018-09-18 16:50 ` David Woodhouse 2018-09-18 17:24 ` Mark Brown 1 sibling, 1 reply; 162+ messages in thread From: David Woodhouse @ 2018-09-18 16:50 UTC (permalink / raw) To: Mark Brown, Laurent Pinchart; +Cc: mchehab+samsung, Tim Bird, ksummit [-- Attachment #1: Type: text/plain, Size: 847 bytes --] On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote: > On Tue, Sep 18, 2018 at 01:38:09PM +0300, Laurent Pinchart wrote: > > > Would there be some value in creating new git-send-gmail or git-send-outlook > > scripts that would work around the issues with common mail providers ? > > At least with Outlook the problem is partly that Outlook's model of how > e-mail works isn't really able to cope with what we need, it translates > everything into internal formats in a way that is at best fragile for > what we need. Outlook is a pile of crap, but Exchange itself works tolerably these days. It's fairly simple to send and receive patches through Exchange if you don't make the mistake of using Outlook. Perhaps I should add an Exchange Web Services back end to git-send-email so that people can use that instead of SMTP... :) [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5213 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 16:50 ` David Woodhouse @ 2018-09-18 17:24 ` Mark Brown 2018-09-18 19:22 ` David Woodhouse 0 siblings, 1 reply; 162+ messages in thread From: Mark Brown @ 2018-09-18 17:24 UTC (permalink / raw) To: David Woodhouse; +Cc: mchehab+samsung, Tim Bird, ksummit [-- Attachment #1: Type: text/plain, Size: 826 bytes --] On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote: > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote: > > At least with Outlook the problem is partly that Outlook's model of how > > e-mail works isn't really able to cope with what we need, it translates > > everything into internal formats in a way that is at best fragile for > > what we need. > Outlook is a pile of crap, but Exchange itself works tolerably these > days. It's fairly simple to send and receive patches through Exchange > if you don't make the mistake of using Outlook. Unfortunately some people do get forced into that :( > Perhaps I should add an Exchange Web Services back end to > git-send-email so that people can use that instead of SMTP... :) There's a smiley there but I'm pretty sure that'd be really useful for some people. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 17:24 ` Mark Brown @ 2018-09-18 19:22 ` David Woodhouse 2018-09-18 19:30 ` Sasha Levin 0 siblings, 1 reply; 162+ messages in thread From: David Woodhouse @ 2018-09-18 19:22 UTC (permalink / raw) To: Mark Brown; +Cc: mchehab+samsung, Tim Bird, ksummit [-- Attachment #1: Type: text/plain, Size: 1138 bytes --] On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote: > On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote: > > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote: > > > At least with Outlook the problem is partly that Outlook's model of how > > > e-mail works isn't really able to cope with what we need, it translates > > > everything into internal formats in a way that is at best fragile for > > > what we need. > > Outlook is a pile of crap, but Exchange itself works tolerably these > > days. It's fairly simple to send and receive patches through Exchange > > if you don't make the mistake of using Outlook. > > Unfortunately some people do get forced into that :( Into using Exchange sure... but *Outlook*? > > Perhaps I should add an Exchange Web Services back end to > > git-send-email so that people can use that instead of SMTP... :) > > There's a smiley there but I'm pretty sure that'd be really useful for > some people. Seriously though, what James and I do with git-format-patch into Evolution's Drafts folder and then just sending from there, should work for fairly much anyone. [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5213 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 19:22 ` David Woodhouse @ 2018-09-18 19:30 ` Sasha Levin 2018-09-18 19:38 ` Josh Triplett 2018-09-18 19:48 ` David Woodhouse 0 siblings, 2 replies; 162+ messages in thread From: Sasha Levin @ 2018-09-18 19:30 UTC (permalink / raw) To: David Woodhouse; +Cc: mchehab+samsung, Tim Bird, ksummit On Tue, Sep 18, 2018 at 08:22:59PM +0100, David Woodhouse wrote: >On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote: >> On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote: >> > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote: >> > > At least with Outlook the problem is partly that Outlook's model of how >> > > e-mail works isn't really able to cope with what we need, it translates >> > > everything into internal formats in a way that is at best fragile for >> > > what we need. >> > Outlook is a pile of crap, but Exchange itself works tolerably these >> > days. It's fairly simple to send and receive patches through Exchange >> > if you don't make the mistake of using Outlook. >> >> Unfortunately some people do get forced into that :( > >Into using Exchange sure... but *Outlook*? Yes, an example is when corp policy forces 2FA auth for exachange. I'm not aware of any non-outlook apps that support that. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 19:30 ` Sasha Levin @ 2018-09-18 19:38 ` Josh Triplett 2018-09-18 19:48 ` David Woodhouse 1 sibling, 0 replies; 162+ messages in thread From: Josh Triplett @ 2018-09-18 19:38 UTC (permalink / raw) To: Sasha Levin; +Cc: mchehab+samsung, Tim Bird, ksummit On Tue, Sep 18, 2018 at 07:30:41PM +0000, Sasha Levin via Ksummit-discuss wrote: > On Tue, Sep 18, 2018 at 08:22:59PM +0100, David Woodhouse wrote: > >On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote: > >> On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote: > >> > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote: > >> > > At least with Outlook the problem is partly that Outlook's model of how > >> > > e-mail works isn't really able to cope with what we need, it translates > >> > > everything into internal formats in a way that is at best fragile for > >> > > what we need. > >> > Outlook is a pile of crap, but Exchange itself works tolerably these > >> > days. It's fairly simple to send and receive patches through Exchange > >> > if you don't make the mistake of using Outlook. > >> > >> Unfortunately some people do get forced into that :( > > > >Into using Exchange sure... but *Outlook*? > > Yes, an example is when corp policy forces 2FA auth for exachange. I'm > not aware of any non-outlook apps that support that. At that point, I wonder if the best bet would be "don't use that email account for patches". ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-18 19:30 ` Sasha Levin 2018-09-18 19:38 ` Josh Triplett @ 2018-09-18 19:48 ` David Woodhouse 1 sibling, 0 replies; 162+ messages in thread From: David Woodhouse @ 2018-09-18 19:48 UTC (permalink / raw) To: Sasha Levin; +Cc: mchehab+samsung, Tim Bird, ksummit [-- Attachment #1: Type: text/plain, Size: 1323 bytes --] On Tue, 2018-09-18 at 19:30 +0000, Sasha Levin wrote: > On Tue, Sep 18, 2018 at 08:22:59PM +0100, David Woodhouse wrote: > > On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote: > > > On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote: > > > > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote: > > > > > At least with Outlook the problem is partly that Outlook's model of how > > > > > e-mail works isn't really able to cope with what we need, it translates > > > > > everything into internal formats in a way that is at best fragile for > > > > > what we need. > > > > > > > > Outlook is a pile of crap, but Exchange itself works tolerably these > > > > days. It's fairly simple to send and receive patches through Exchange > > > > if you don't make the mistake of using Outlook. > > > > > > Unfortunately some people do get forced into that :( > > > > Into using Exchange sure... but *Outlook*? > > Yes, an example is when corp policy forces 2FA auth for exachange. I'm > not aware of any non-outlook apps that support that. https://wiki.gnome.org/Apps/Evolution/EWS/OAuth2 That seems harder than it should be, but apparently works for some. cf. https://bugzilla.gnome.org/show_bug.cgi?id=775690 If you have suggestions to improve it, I'm sure they would be welcomed... [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5213 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 14:59 ` Mauro Carvalho Chehab 2018-09-17 22:39 ` Dave Airlie @ 2018-09-18 8:24 ` Eric W. Biederman 1 sibling, 0 replies; 162+ messages in thread From: Eric W. Biederman @ 2018-09-18 8:24 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss Mauro Carvalho Chehab <mchehab+samsung@kernel.org> writes: > Em Mon, 17 Sep 2018 17:14:29 +0300 > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > >> On Monday, 17 September 2018 16:04:13 EEST Mauro Carvalho Chehab wrote: >> > Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven escreveu: >> > > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab wrote: >> > >> The communication traffic between the developers there is usually >> > >> not relevant (nor wanted) at LKML. >> >> Not on LKML, but it should be public, searchable and mirrored, not hidden >> behind an authentication, or stored in a single location. > > Yeah, being public and searchable are important features. > > However, nowadays, the concept of "stored in a single location" is > something that doesn't make much sense: most of stuff are stored on > clouds, specially if one is using a big service provider. On a cloud > service, the concept of "mirrored" also is not relevant: a single > URL usually is handled by multiple servers. Usually, it is invisible > to the users what is the real infrastructure behind the service. But "single point of failure" continues to be relevant. It is straight forward to have a personal archive of a mailing list. Not so much with other solutions. >> > >> What we usually do on normal subsystems is to have those discussions >> > >> "filtered" on a separate mailing list. I don't see why not use a >> > >> web-based interface for such purpose. >> >> There are multiple reasons. One of them is that you'll lose the whole history >> the day the project is deleted from gitlab, github or any other single >> provider. > > This can happen whatever infra is used. That's why the git logs should be > clear enough to not depend on it. I'm pretty sure that, whatever we use > nowadays (even mirrored ML logs) will some day be replaced by something > else. Try to seek, for example, for the old usenet messages. The only > thing that is more warranted to survive as time goes by are the patch > logs. It is absolutely reasonable to expect discussions to be public and to build the infrastructure to make it happen. Certainly such archives have been invaluable in my work on the kernel for tracking down why do the things that we do in the kernel. One of the more interesting developments in this area recently is the public-inbox project, and it's use in lore.kernel.org. I know have all of the archives of linux-kernel sitting in a little git archive on my laptop. Depending on what I am doing a local git-grep can be more productive than looking at the the nice searchable web archive. It is my hope that as this method of mirroring and archiving a mailling list become more common sites like github and gitlab will adopt similar strategies for the discussion that happen on their sites. Eric ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 11:43 ` Mauro Carvalho Chehab 2018-09-17 12:03 ` Geert Uytterhoeven @ 2018-09-17 13:12 ` Christoph Hellwig 2018-09-17 14:14 ` Mauro Carvalho Chehab 2018-09-17 21:59 ` Rafael J. Wysocki 1 sibling, 2 replies; 162+ messages in thread From: Christoph Hellwig @ 2018-09-17 13:12 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote: > While I do agree that the main Kernel development should happen via > email on the foreseen future, Why e-mail would be a mandatory > requirement for all kinds of Kernel development? > > I don't believe that a single development model fits all cases. > > Let's say that someone is using something like github to manage the > development of a single driver - or even a low traffic subsystem. Sadly enough that already is the case. The ACPI maintainers refuse to take perfectly fine patches and instead redirect people to a github version (which doesn't look like the kernel code at all), which requires a signup with a not exactly trust-worthy webservice. I don't think we should care how a subsystem is managed internally as long as they accept perfectly fine formatted patches by email. ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:12 ` Christoph Hellwig @ 2018-09-17 14:14 ` Mauro Carvalho Chehab 2018-09-17 21:59 ` Rafael J. Wysocki 1 sibling, 0 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 14:14 UTC (permalink / raw) To: Christoph Hellwig; +Cc: ksummit-discuss Em Mon, 17 Sep 2018 06:12:18 -0700 Christoph Hellwig <hch@infradead.org> escreveu: > On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote: > > While I do agree that the main Kernel development should happen via > > email on the foreseen future, Why e-mail would be a mandatory > > requirement for all kinds of Kernel development? > > > > I don't believe that a single development model fits all cases. > > > > Let's say that someone is using something like github to manage the > > development of a single driver - or even a low traffic subsystem. > > Sadly enough that already is the case. The ACPI maintainers refuse > to take perfectly fine patches and instead redirect people to a > github version (which doesn't look like the kernel code at all), > which requires a signup with a not exactly trust-worthy webservice. > > I don't think we should care how a subsystem is managed internally > as long as they accept perfectly fine formatted patches by email. Fully agreed. IMO, a mandatory requirement is that anyone that uses a development model that would refuse a perfectly fine patch sent via a plain e-mail from a non-subscriber should ensure that, if such email is ever received, it will be properly handled. IMO, we should add such rule on our patch development process docs (if not there already), and if abuses are happening, see what it can be done to fix it. In other words, in the case of a moderated ML, it should be up to the ML maintainers to accept valid patch emails, without requiring occasional contributors to subscribe. The same rule should apply to github-like development: it should be up to the maintainers to do whatever it is needed for such patches to be handled on their development model. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 13:12 ` Christoph Hellwig 2018-09-17 14:14 ` Mauro Carvalho Chehab @ 2018-09-17 21:59 ` Rafael J. Wysocki 2018-09-17 22:17 ` Rafael J. Wysocki 1 sibling, 1 reply; 162+ messages in thread From: Rafael J. Wysocki @ 2018-09-17 21:59 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Mauro Carvalho Chehab, ksummit-discuss On Monday, September 17, 2018 3:12:18 PM CEST Christoph Hellwig wrote: > On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote: > > While I do agree that the main Kernel development should happen via > > email on the foreseen future, Why e-mail would be a mandatory > > requirement for all kinds of Kernel development? > > > > I don't believe that a single development model fits all cases. > > > > Let's say that someone is using something like github to manage the > > development of a single driver - or even a low traffic subsystem. > > Sadly enough that already is the case. The ACPI maintainers refuse > to take perfectly fine patches and instead redirect people to a > github version (which doesn't look like the kernel code at all), > which requires a signup with a not exactly trust-worthy webservice. That's ACPICA to be precise and that's because it is a separate project really that's used by the kernel. It generally is better to get patches to the upstream first and to the kernel from there. That's nothing new, though, it's been like that for years. Cheers, Rafael ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-17 21:59 ` Rafael J. Wysocki @ 2018-09-17 22:17 ` Rafael J. Wysocki 0 siblings, 0 replies; 162+ messages in thread From: Rafael J. Wysocki @ 2018-09-17 22:17 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Mauro Carvalho Chehab, ksummit-discuss On Monday, September 17, 2018 11:59:22 PM CEST Rafael J. Wysocki wrote: > On Monday, September 17, 2018 3:12:18 PM CEST Christoph Hellwig wrote: > > On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote: > > > While I do agree that the main Kernel development should happen via > > > email on the foreseen future, Why e-mail would be a mandatory > > > requirement for all kinds of Kernel development? > > > > > > I don't believe that a single development model fits all cases. > > > > > > Let's say that someone is using something like github to manage the > > > development of a single driver - or even a low traffic subsystem. > > > > Sadly enough that already is the case. The ACPI maintainers refuse > > to take perfectly fine patches and instead redirect people to a > > github version (which doesn't look like the kernel code at all), > > which requires a signup with a not exactly trust-worthy webservice. > > That's ACPICA to be precise and that's because it is a separate project really > that's used by the kernel. It generally is better to get patches to the > upstream first and to the kernel from there. > > That's nothing new, though, it's been like that for years. Also they do take patches from email (they may not prefer to do it this way, but still), but those patches need to be against the upstream code base which, indeed, uses a different coding style and other conventions. Cheers, Rafael ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 20:32 ` Laurent Pinchart 2018-09-10 20:55 ` Daniel Vetter 2018-09-10 21:11 ` Theodore Y. Ts'o @ 2018-09-10 21:19 ` Konstantin Ryabitsev 2018-09-11 8:33 ` Rafael J. Wysocki 2 siblings, 1 reply; 162+ messages in thread From: Konstantin Ryabitsev @ 2018-09-10 21:19 UTC (permalink / raw) To: Laurent Pinchart, ksummit-discuss [-- Attachment #1.1: Type: text/plain, Size: 2826 bytes --] On 9/10/18 4:32 PM, Laurent Pinchart wrote: > If we want to challenge that, we'll have to agree about another communication > system for the whole kernel. While I don't think that's realistic, I'm not > opposed to discussing it. However, I expect many developers to come up with > lists of requirements, and the result of merging all those requirements > together to be exactly email and nothing else :-) > > On my side, there are three very important features that a communication > system should have: > > - It should be push-based. I don't want to have to log in and pull information > from web UIs. > > - It should be customizable, offering an easy way to script review, and patch > and pull request handling. > > - It should offer an offline mode. Lots of us travel a lot or generally have > to work without an internet connection more often than we would like, so any > solution that requires being online won't work. This is part of the reason why I mentioned pagure.io in a different thread -- it is mostly a web-ui sitting on top of gitolite and was written with an eye to be fully workable via ssh and email: https://docs.pagure.org/pagure/overview.html#overview With Pagure, *theoretically* (I haven't looked in any depth into any of it), everyone who is happy with the current gitolite/email workflow would just continue using their existing routine. Anyone who wants to use the UI for issue tracking and pull requests can optionally choose to do so. Since it uses gitolite, there wouldn't be a "flag day" where everyone would have to switch to the new workflow. It is used by Fedora and therefore, I guess, is to some degree "backed" by Red Hat (in the same sense as how Fedora is "backed" by Red Hat). It also has the benefit of not suffering from the "community edition" vs. "commercial edition" duality that GitLab has. From my experience using Puppet, I know how tempting it is for orgs to prevent useful features from making it into the "community edition" if they can charge for them instead. That said, I'm not sure if this would actually reduce confusion instead of creating more. We know for a fact that central issue tracking a-la Github would fail for the kernel unless there is someone in a janitorial^W heroic position of figuring out to whom assign each incoming bug. I also know from experience that almost every web UI tool written to work with git chokes and fails on something as large as the kernel or when hit with a firehose of chatter like LKML. In other words, I'm not at all ra-ra about implementing this, but if there is enough consensus that it's worth trying out, I will be happy to set something up for a test spin. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 21:19 ` Konstantin Ryabitsev @ 2018-09-11 8:33 ` Rafael J. Wysocki 0 siblings, 0 replies; 162+ messages in thread From: Rafael J. Wysocki @ 2018-09-11 8:33 UTC (permalink / raw) To: ksummit-discuss; +Cc: Konstantin Ryabitsev On Monday, September 10, 2018 11:19:41 PM CEST Konstantin Ryabitsev wrote: > On 9/10/18 4:32 PM, Laurent Pinchart wrote: > > If we want to challenge that, we'll have to agree about another communication > > system for the whole kernel. While I don't think that's realistic, I'm not > > opposed to discussing it. However, I expect many developers to come up with > > lists of requirements, and the result of merging all those requirements > > together to be exactly email and nothing else :-) > > > > On my side, there are three very important features that a communication > > system should have: > > > > - It should be push-based. I don't want to have to log in and pull information > > from web UIs. > > > > - It should be customizable, offering an easy way to script review, and patch > > and pull request handling. > > > > - It should offer an offline mode. Lots of us travel a lot or generally have > > to work without an internet connection more often than we would like, so any > > solution that requires being online won't work. > > This is part of the reason why I mentioned pagure.io in a different > thread -- it is mostly a web-ui sitting on top of gitolite and was > written with an eye to be fully workable via ssh and email: > > https://docs.pagure.org/pagure/overview.html#overview > > With Pagure, *theoretically* (I haven't looked in any depth into any of > it), everyone who is happy with the current gitolite/email workflow > would just continue using their existing routine. Anyone who wants to > use the UI for issue tracking and pull requests can optionally choose to > do so. Since it uses gitolite, there wouldn't be a "flag day" where > everyone would have to switch to the new workflow. > > It is used by Fedora and therefore, I guess, is to some degree "backed" > by Red Hat (in the same sense as how Fedora is "backed" by Red Hat). It > also has the benefit of not suffering from the "community edition" vs. > "commercial edition" duality that GitLab has. From my experience using > Puppet, I know how tempting it is for orgs to prevent useful features > from making it into the "community edition" if they can charge for them > instead. > > That said, I'm not sure if this would actually reduce confusion instead > of creating more. We know for a fact that central issue tracking a-la > Github would fail for the kernel unless there is someone in a > janitorial^W heroic position of figuring out to whom assign each > incoming bug. And knowledge and enough power to make the relevant party actually take care of the report. And even with all that it sometimes isn't clear where the problem is to start with and some debug work needs to be done upfront. > I also know from experience that almost every web UI tool > written to work with git chokes and fails on something as large as the > kernel or when hit with a firehose of chatter like LKML. Right. Cheers, Rafael ^ permalink raw reply [flat|nested] 162+ messages in thread
* [Ksummit-discuss] Fwd: [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 14:53 ` Linus Torvalds ` (2 preceding siblings ...) 2018-09-10 15:56 ` Daniel Vetter @ 2018-09-10 16:29 ` Daniel Vetter 2018-09-11 15:35 ` [Ksummit-discuss] " Jiri Kosina 2018-09-17 11:11 ` [Ksummit-discuss] [MAINTAINER SUMMIT] Live without email - possible? - Was: " Mauro Carvalho Chehab 5 siblings, 0 replies; 162+ messages in thread From: Daniel Vetter @ 2018-09-10 16:29 UTC (permalink / raw) To: ksummit, Linus Torvalds On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >> >> I think for pratical reasons (the linux kernel is huge) focusing on >> subsystems is more useful, at least in the short term. Much easier to >> experiment with new things in smaller groups. > > I think that realistically, it's never going to be anything *but* > subsystem-specific, not just because the kernel is huge. > > There are simply often very different concerns. > > An individual filesystem can be a big project, and people work on > filesystems for decades. They can get quite complex indeed. But at the > same time, an individual filesystem just doesn't tend to *impact* > other things. Sure, we may end up adding features to the VM or the VFS > layer to make it possible for it to do some particular thing, and we > may end up having lots of common code that a lot of filesystems end up > sharing, but in a very real sense, it is its own _mostly_ independent > thing, and what happens inside the community for that filesystem > doesn't tend to much affect anybody else. > > Same goes for a lot of drivers. Yes, they have connections to the > outside, but what happens in one driver seldom affects anything else. > > Equally importantly, filesystem changes can generally be tested with a > fairly targeted test-suite. When you make changes to one filesystem, > you need to test only _that_ filesystem. > > The same _tends_ to be true for drivers too, although there testing > can be "interesting" because of the hardware dependency - a single > driver often covers a few tens (to a few hundred) different hardware > implementations. But the changes still don't tend to affect *other* > devices. > > But things change once you start going up from individual filesystems > or drivers to a common layer. Making changes to a common layer is > simply _fundamentally_ way more painful. Sure, part of the pain is > that now you have to convert all the filesystems or drivers that > depended on that common layer to the new changes, but a large part is > simply that now the changes affect many different kinds of filesystems > or drivers, and testing is *much* harder. > > You obviously see that with the whole drm layer (example: atomic > modesetting). That's still a fairly small set of different drivers > (small in number, not in code-size), and it already causes issues. > > At the other end of the spectrum, some of the most painful changes > we've ever done have basically gone across *all* drivers, and caused > untold bugs for the better part of a decade. I'm thinking of all the > power management work we did back ten+ years ago. > > The VM people (and some other groups - the scheduler comes to mind) > have had a different kind of issue entirely: not that the kernel has > tons of "sub-drivers" that depend on them - although that obviously is > true in a very real sense for any memory allocator etc - but simply > that there are lots of different loads. In a filesystem or a driver, > you can have a test-suite for correct behavior, but the behavior is > largely the same. When it comes to VM or scheduler, the problem is > that you have different loads, and performing well on one load does > not mean at all that you do well on another. > > We had a few years when people were pushing scheduler rchanges without > really appreciating that "your load isn't everybody elses load" issue. > > In contrast, in drivers and filesystems, things are usually more > black-and-white wrt "does this work well". Yes, yes, you have latency > vs throughput issues etc, and you might have some scalability issues > with per-cpu queues etc, but at the individual driver level, those > kinds of concerns tend to not dominate. You want a stress-test setup > for testing, but you don't need to worry too much about lots of crazy > users. > > So different areas of the kernel just tend to have different concerns. > You can allow people to work more freely on a driver that doesn't > affect other things than on something that possibly screws over a lot > of other developers. > > But if we find "models that work", maybe we can at least have > processes that look a bit more like each other, even across > subsystems. Yeah, fully agreed, I think this is the kernel community's real strength. It's one overall project on one hand, everyone pushes into the exact same directory structure with one overall git history (in the end at least, once something has made it to upstream). But zooming in, it's very much just a loosely-coupled pile of associated projects; each can optimize for their local constraints. HW testing and hacking is indeed totally different from core work that affects everyone. This also ties somewhat into the gitlab discussions: github doesn't support this model, and isn't interested in fixing this. gitlab at least has made some foundational work in their internals already (how they handle the fork tree mostly, since that's the big one), and they're interested in exploring how to support something like the kernel's git tree flow at a higher level, in their web UI. I wrote this entire thing up semi-coherently a while ago on my blog: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html >> That's why I added >> "subsystem governance". If there's enough interest on specific topics >> we could schedule some BOF sessions, otherwise just hallway track with >> interested parties. > > So what I think would be good is to not talk about some nebulous > "community management", but talk about very specific and very real > examples of actual technical problems. > > Partly exactly *because* I think the areas are not all the same, and > the friction points are likely *between* these areas that may even > have really good reasons to act differently, and mostly they are > independent and have little interaction, but then when interaction > happens, things don't work well. > > IOW, if we have the top-level maintainers around, we should have a > gripe-fest where people come in and say "Hey, you, look, this > *particular* problem has been around for a year now, there's a patch, > why did it not get applied"? > > Don't make it about some nebulous "we could do better as a community". > > Instead, make it about some very *particular* issue where the process > failed. Make it something concrete and practical. > > "Look, this patch took a year to get in, for no good reason". > > Or > > "Look, here's a feature that I *tried* to get accepted for a month, > nothing happened, so I gave up". > > And if we have a few of those, maybe we can see a pattern, and perhaps > even come up with some suggestion on how to fix some flow. > > And if people can't come up with particular examples, I don't think > it's much worth discussing. At that point it's not productive. > > We need to name names, show patches, and talk about exactly where and > how something broke down. Yeah, it's much easier to discuss concrete stuff than high-level abstract concepts. That's why I listed a bunch of specific things I'm interested in. Mostly that's stuff I'm actively working on in areas that arent working perfectly in drm. Or at least where things are painful enough that we're grasping for anything that looks like it might help. And if no one cares for a specific topic, then we'll best just throw it off the agenda instead of having a generic discussion that goes nowhere. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 162+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance 2018-09-10 14:53 ` Linus Torvalds ` (3 preceding siblings ...) 2018-09-10 16:29 ` [Ksummit-discuss] Fwd: " Daniel Vetter @ 2018-09-11 15:35 ` Jiri Kosina 2018-09-17 11:11 ` [Ksummit-discuss] [MAINTAINER SUMMIT] Live without email - possible? - Was: " Mauro Carvalho Chehab 5 siblings, 0 replies; 162+ messages in thread From: Jiri Kosina @ 2018-09-11 15:35 UTC (permalink / raw) To: Linus Torvalds; +Cc: ksummit On Mon, 10 Sep 2018, Linus Torvalds wrote: > For example, we've had the "trivial tree", which tends to be a really > thankless project, that might well be managed way more easily by just > having a random tree that lots of people can commit to, and we could > even encourage the github (gitlab?) model of random non-kernel people > just sending their random trees to it, and have then the group of > committers be able to merge the changes (and at least on github, the > default merge is just a fast-forward, so it actually acts more like a > patch queue than a git tree). > > And the reason I mention the trivial tree is not because the trivial > tree itself is all that interesting or because I'd like to belittle > that model ("that will only work for trivial unimportant stuff"), but > because it might be a good area to experiment in, and a way to get > people used to the flow. For whatever that is worth -- I have had absolutely zero time to maintain that tree for past ~1 year, so I am open to any changes there that would make sense :) Suggestions / help offers welcome. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 162+ messages in thread
* [Ksummit-discuss] [MAINTAINER SUMMIT] Live without email - possible? - Was: community management/subsystem governance 2018-09-10 14:53 ` Linus Torvalds ` (4 preceding siblings ...) 2018-09-11 15:35 ` [Ksummit-discuss] " Jiri Kosina @ 2018-09-17 11:11 ` Mauro Carvalho Chehab 5 siblings, 0 replies; 162+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 11:11 UTC (permalink / raw) To: Linus Torvalds; +Cc: ksummit Em Mon, 10 Sep 2018 04:53:07 -1000 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > So let me suggest a topic for the maintainer summit: > > "Live without email - possible?" > > just to get that ball rolling (I did a little reorder here, to place the new topic proposal at the beginning) ... > I've not used gitlab personally, but I *have* used github for a much > smaller project. > > I have to say, the random and relaxed model is enjoyable. I can see > how somebody coming from that, then finds the strict kernel rules (and > _different_ rules for different parts) off-putting and confusing. With the risk of getting somewhat offtopic, let me give some hints from my personal experience with github. I'm currently hosting some EDAC/RAS tools and some media userspace stuff on github (and a few other random stuff). I also contributed with some solaar patches in the past, addressing some hardware issues with the mouse I use here. A couple of weeks ago got commit rights on a camera application (camorama). So, I have not only things hosted by me and projects that I contribute, but also things hosted by someone else there with commit rights. Yeah, for projects maintained by a small number of developers, a web interface like github provides additional value over a single git host site, as it provides a lightweight interface for bugtrack/issues, it allows threaded comments on pull requests, and it allows seeing all (publicly available) forks. Another interesting feature is that, if someone add more patches to a branch that it is part of a pull request (or rebase it), their interface automatically reflects it. So, it avoids merging old stuff, if you handle pull requests via the web interface[1]. [1] From security PoV, this can be risky, as you might end merging something wrong, if someone steals the credentials of the original committer. One thing that I didn't try yet is how it would handle GPG-signed tags. It works nice on projects with a small number of maintainers/developers. That's said, I don't think that such model would scale for the Kernel as a hole. IMO, the number of issues and pull requests will make it messy and easy to lose something. The same likely applies to high-traffic subsystems like media. For low traffic subsystems however, I can see such model would work pretty well, as it would not only provide a simple centralized repository for the subsystem, but would also work as a forum where people could add issues, comment on pull requests, create development forks, etc. Also, "Gen-Y/Gen-Z" developers are likely more familiar with such kind of interface, so it has the potential to attract new blood to the Kernel than e-mail discussions. I guess we could experiment using it on some small subsystems and see how well it would work. Thanks, Mauro ^ permalink raw reply [flat|nested] 162+ messages in thread
end of thread, other threads:[~2018-09-21 23:13 UTC | newest] Thread overview: 162+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-10 8:59 [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance Daniel Vetter 2018-09-10 14:53 ` Linus Torvalds 2018-09-10 15:08 ` James Bottomley 2018-09-10 15:10 ` Linus Torvalds 2018-09-10 15:38 ` Sasha Levin 2018-09-10 15:47 ` James Bottomley 2018-09-10 15:55 ` Sasha Levin 2018-09-10 16:13 ` James Bottomley 2018-09-10 16:24 ` Sasha Levin 2018-09-10 17:10 ` James Bottomley 2018-09-10 15:47 ` Konstantin Ryabitsev 2018-09-10 15:56 ` Sasha Levin 2018-09-10 16:02 ` Konstantin Ryabitsev 2018-09-10 16:07 ` Daniel Vetter 2018-09-10 16:18 ` Konstantin Ryabitsev 2018-09-10 16:23 ` Daniel Vetter 2018-09-10 16:41 ` Konstantin Ryabitsev 2018-09-10 17:06 ` Daniel Vetter 2018-09-10 19:48 ` Laurent Pinchart 2018-09-10 20:50 ` Daniel Vetter 2018-09-10 15:49 ` Mark Brown 2018-09-10 16:33 ` Olof Johansson 2018-09-10 19:59 ` Laurent Pinchart 2018-09-10 21:30 ` Josh Triplett 2018-09-10 23:00 ` Laurent Pinchart 2018-09-10 23:16 ` Daniel Vetter 2018-09-11 1:14 ` Josh Triplett 2018-09-10 15:13 ` Jiri Kosina 2018-09-10 15:20 ` James Bottomley 2018-09-10 15:31 ` Sasha Levin 2018-09-10 20:15 ` Laurent Pinchart 2018-09-10 21:09 ` Sean Paul 2018-09-10 21:38 ` Laurent Pinchart 2018-09-11 10:06 ` Leon Romanovsky 2018-09-11 8:44 ` Jani Nikula 2018-09-11 9:08 ` Geert Uytterhoeven 2018-09-11 10:01 ` Daniel Vetter 2018-09-11 10:09 ` Geert Uytterhoeven 2018-09-11 10:17 ` Daniel Vetter 2018-09-11 10:30 ` Geert Uytterhoeven 2018-09-11 8:41 ` Jani Nikula 2018-09-10 15:31 ` Daniel Vetter 2018-09-10 16:39 ` Olof Johansson 2018-09-10 17:10 ` Daniel Vetter 2018-09-12 19:02 ` Darren Hart 2018-09-12 18:59 ` Darren Hart 2018-09-12 20:05 ` Daniel Vetter 2018-09-12 20:58 ` Darren Hart 2018-09-13 11:27 ` Mark Brown 2018-09-13 11:41 ` Daniel Vetter 2018-09-13 17:08 ` Darren Hart 2018-09-13 2:56 ` Theodore Y. Ts'o 2018-09-13 5:17 ` Daniel Vetter 2018-09-10 15:56 ` Daniel Vetter 2018-09-10 20:32 ` Laurent Pinchart 2018-09-10 20:55 ` Daniel Vetter 2018-09-10 21:33 ` Laurent Pinchart 2018-09-10 22:44 ` Daniel Vetter 2018-09-11 12:44 ` Alexandre Belloni 2018-09-11 14:35 ` Mark Brown 2018-09-11 15:17 ` Alexandre Belloni 2018-09-11 15:02 ` Daniel Vetter 2018-09-11 22:00 ` Alexandre Belloni 2018-09-11 22:17 ` Guenter Roeck 2018-09-12 8:42 ` Jani Nikula 2018-09-12 18:45 ` Alexandre Belloni 2018-09-12 19:52 ` Dave Airlie 2018-09-12 22:25 ` Daniel Vetter 2018-09-12 9:14 ` Linus Walleij 2018-09-12 18:23 ` Alexandre Belloni 2018-09-12 18:44 ` Thomas Gleixner 2018-09-13 12:08 ` Maxime Ripard 2018-09-13 12:57 ` Alexandre Belloni 2018-09-13 13:18 ` Maxime Ripard 2018-09-13 14:25 ` Jani Nikula 2018-09-13 20:05 ` Thomas Gleixner 2018-09-13 23:02 ` Rodrigo Vivi 2018-09-14 6:47 ` Rafael J. Wysocki 2018-09-14 6:39 ` Dave Airlie 2018-09-14 14:15 ` Thomas Gleixner 2018-09-17 7:40 ` Daniel Vetter 2018-09-14 7:08 ` Linus Walleij 2018-09-14 7:39 ` Geert Uytterhoeven 2018-09-14 8:08 ` Linus Walleij 2018-09-12 21:21 ` Linus Walleij 2018-09-21 16:05 ` Joe Perches 2018-09-12 22:44 ` Laurent Pinchart 2018-09-10 22:56 ` Laurent Pinchart 2018-09-10 21:11 ` Theodore Y. Ts'o 2018-09-10 23:05 ` Laurent Pinchart 2018-09-17 11:43 ` Mauro Carvalho Chehab 2018-09-17 12:03 ` Geert Uytterhoeven 2018-09-17 13:04 ` Mauro Carvalho Chehab 2018-09-17 13:10 ` Julia Lawall 2018-09-17 13:29 ` Christoph Hellwig 2018-09-17 13:48 ` Laurent Pinchart 2018-09-17 13:58 ` Mauro Carvalho Chehab 2018-09-17 14:18 ` Christoph Hellwig 2018-09-17 14:50 ` Geert Uytterhoeven 2018-09-17 15:21 ` Mauro Carvalho Chehab 2018-09-17 14:18 ` Laurent Pinchart 2018-09-17 16:50 ` Joe Perches 2018-09-17 14:14 ` Laurent Pinchart 2018-09-17 14:59 ` Mauro Carvalho Chehab 2018-09-17 22:39 ` Dave Airlie 2018-09-17 23:04 ` James Bottomley 2018-09-18 8:00 ` Daniel Vetter 2018-09-18 11:16 ` James Bottomley 2018-09-18 15:26 ` Randy Dunlap 2018-09-18 16:47 ` Tim.Bird 2018-09-18 16:59 ` Konstantin Ryabitsev 2018-09-18 17:08 ` Tim.Bird 2018-09-18 17:12 ` Tim.Bird 2018-09-18 17:31 ` Konstantin Ryabitsev 2018-09-18 17:42 ` Tim.Bird 2018-09-18 17:55 ` Konstantin Ryabitsev 2018-09-18 18:58 ` Tim.Bird 2018-09-18 19:24 ` Konstantin Ryabitsev 2018-09-18 17:47 ` Geert Uytterhoeven 2018-09-18 17:49 ` Greg KH 2018-09-18 18:03 ` Konstantin Ryabitsev 2018-09-18 22:46 ` Alexandre Belloni 2018-09-18 18:22 ` Dmitry Torokhov 2018-09-18 19:16 ` Theodore Y. Ts'o 2018-09-18 18:56 ` Sasha Levin 2018-09-18 23:05 ` Laurent Pinchart 2018-09-18 7:37 ` Nicolas Ferre 2018-09-18 7:47 ` Geert Uytterhoeven 2018-09-18 10:38 ` Laurent Pinchart 2018-09-18 16:02 ` Mark Brown 2018-09-18 16:32 ` Luck, Tony 2018-09-18 16:35 ` Dmitry Torokhov 2018-09-18 17:18 ` Linus Torvalds 2018-09-18 17:28 ` Sean Paul 2018-09-18 17:37 ` Tim.Bird 2018-09-21 16:46 ` Olof Johansson 2018-09-21 17:08 ` Mauro Carvalho Chehab 2018-09-21 17:16 ` Olof Johansson 2018-09-18 17:21 ` Mark Brown 2018-09-18 21:01 ` Steven Rostedt 2018-09-18 23:16 ` Laurent Pinchart 2018-09-18 23:54 ` Mark Brown 2018-09-19 5:27 ` Christoph Hellwig 2018-09-19 9:46 ` James Bottomley 2018-09-18 17:10 ` Tim.Bird 2018-09-18 20:48 ` Takashi Iwai 2018-09-18 16:50 ` David Woodhouse 2018-09-18 17:24 ` Mark Brown 2018-09-18 19:22 ` David Woodhouse 2018-09-18 19:30 ` Sasha Levin 2018-09-18 19:38 ` Josh Triplett 2018-09-18 19:48 ` David Woodhouse 2018-09-18 8:24 ` Eric W. Biederman 2018-09-17 13:12 ` Christoph Hellwig 2018-09-17 14:14 ` Mauro Carvalho Chehab 2018-09-17 21:59 ` Rafael J. Wysocki 2018-09-17 22:17 ` Rafael J. Wysocki 2018-09-10 21:19 ` Konstantin Ryabitsev 2018-09-11 8:33 ` Rafael J. Wysocki 2018-09-10 16:29 ` [Ksummit-discuss] Fwd: " Daniel Vetter 2018-09-11 15:35 ` [Ksummit-discuss] " Jiri Kosina 2018-09-17 11:11 ` [Ksummit-discuss] [MAINTAINER SUMMIT] Live without email - possible? - Was: " Mauro Carvalho Chehab
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.