* [Ksummit-discuss] "Maintainer summit" invitation discussion @ 2017-04-18 18:59 Linus Torvalds 2017-04-18 19:50 ` Takashi Iwai ` (9 more replies) 0 siblings, 10 replies; 135+ messages in thread From: Linus Torvalds @ 2017-04-18 18:59 UTC (permalink / raw) To: ksummit Cc: Ingo Molnar, Dave Airlie, Greg Kroah-Hartman, Doug Ledford, David Miller The kernel summit is apparently in October, and I promised last year to at least get the ball rolling with the people *I* would like to see. I even subscribed to this list, though I promised myself I wouldn't get involved in any other discussion. I've actually churned the numbers several ways, none of which really make me convinced that metric matters much. Looking at actual developers (actually, I generally just did "committers" rather than actual "authors"), you can certainly just do it by number of commits (or sizes of commits, or numbers of files touched), all of which I tried, and all of which actually got fairly similar "top 20" lists. And none of those "top 20" lists looked precisely wrong, but they didn't look precisely right either. So being in the quiet "late rc" period, I decided to try to just do statistics over who I pull from, and how much I pull instead. Which is much closer to that "maintainer summit" I think I want. And the end result actually looks not unreasonable when I do that. I ended up approximating the sorting by "cumulative files changed" (ie just counting number of files changed for each pull request I do: so the same file will count N times if it shows up in N pull requests). Like all the other metrics I tried, it does end up skewing one way or the other: people who touch a lot of files in trivial ways get counted more, but looking at the list I don't see anything really odd anywhere. In particular, with that metric I get the obvious two top maintainers being David Miller and Greg KH - which would be pretty much a requirement for any sane maintainership counting algorithm. The tip and arm maintainers also show up, although they obviously get diluted by spreading out their work. You can see the "top 10" list by just looking at the Cc of this email. That one looks sane too, and contains the main architectures (x86, arm, powerpc) and the biggest driver subsystems (drm, media, sound and rdma). And Andrew Morton. None of the filesystem people show up in the top 10, although Al does show up at spot 11, and individual filesystems show up lower down the list (mainly just xfs and ext4). What I _would_ like to see is those top maintainers suggest "submaintainer" names. Particularly Davem, since he doesn't tend to want to come to the kernel summit, and being at the top of the list that's a kind of big gaping hole. I guess we haven't had all that many _problems_ within networking, but if we talk maintainership issues, it's certainly a bit odd if it's entirely lacking. We have both core networking and network drivers that both fall under "davem" as far as my pull statistics go. I'm appending the "top 50" list in its entirely for people to look at - the numbers are the "cumulative files changed in pull requests _directly_ to me over the last 12 months". I'm not saying these people all make sense: I think we should also take other issues into account, and in particular rather than just a fairly straightforward "size of subsystem" it should be about maintenance burden size too. So drm and rdma both show up fairly high on both of those lists, I think, and thus should be part of any maintainership discussion - but maybe some other subsystems just aren't enough of a maintenance headache to worry about? So the other way to split it up is by "maintenance area", ie we have - architectures Pretty much covered by x86, arm, powerpc, and those architectures should talk about who within the group would attend. - drivers Obviously we have Greg overall, with drm and rdma because of issues. An example here is that Christoph doesn't show up because I don't generally pull from him, but he's been all over and often crosses multiple driver subsystems, and has been involved in rdma too, so I'd add him just for that. Some driver subsystems may be huge (eg media and sound), but I don't know if they have issues. Mauro/Takashi? - filesystems Al, XSF and ext4 stand out by size (XFS is mostly Dave Chinner due to me going by past year, but is obviously Darrick Wong right now). - core stuff. We've got Andrew, and I'd add Tejun from the list, with others possible? Maintenance issues here are actually sometimes contentious even if the core kernel is fairly small. - security stuff Luto, Kees? - particular pain points. Any not mentioned? - other? I'd like the maintainership summit list to be fairly small. Not even 50 people. Maybe 30. A group that can actually sit in a room for half a day and talk to each other about the issues they have rather than being talked to. And talk literally about *process* issues, not about any particular technical issues within whatever subsystem. Bring up peeves or wishes for actual process improvements? Comments? People who should be involved? Or people who don't have any particular issues and want to not be involved? Linus ----- 11118 David Miller 6004 Greg KH 5337 Dave Airlie 5114 Ingo Molnar 3918 Mauro Carvalho Chehab 3381 Arnd Bergmann 3096 Andrew Morton 1803 Michael Ellerman 1557 Takashi Iwai 1414 Doug Ledford 1341 Al Viro 1304 Rafael Wysocki 1233 Jens Axboe 1221 Thomas Gleixner 1045 Olof Johansson 980 Linus Walleij 924 James Bottomley 792 Ralf Baechle 788 Herbert Xu 751 Stephen Boyd 593 Martin Schwidefsky 585 Jonathan Corbet 529 Paolo Bonzini 443 Ulf Hansson 443 Bjorn Helgaas 421 Chris Mason 420 Mark Brown 411 Dave Chinner 410 James Morris 399 Michal Marek 383 Dmitry Torokhov 361 Will Deacon 353 Wolfram Sang 320 Jiri Kosina 310 Vineet Gupta 299 Russell King 298 Brian Norris 285 Lee Jones 280 Guenter Roeck 279 Vinod Koul 275 Rob Herring 271 Radim Krčmář 266 James Hogan 251 Alexandre Belloni 239 Sebastian Reichel 221 Ted Ts'o 220 Tejun Heo 215 Dan Williams 210 Shuah Khan 208 Catalin Marinas ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds @ 2017-04-18 19:50 ` Takashi Iwai 2017-04-18 20:13 ` Linus Torvalds 2017-04-18 20:00 ` Dave Airlie ` (8 subsequent siblings) 9 siblings, 1 reply; 135+ messages in thread From: Takashi Iwai @ 2017-04-18 19:50 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, ksummit, Dave Airlie, Greg Kroah-Hartman, Doug Ledford, David Miller On Tue, 18 Apr 2017 20:59:37 +0200, Linus Torvalds wrote: > > - drivers > > Obviously we have Greg overall, with drm and rdma because of issues. > > An example here is that Christoph doesn't show up because I don't > generally pull from him, but he's been all over and often crosses > multiple driver subsystems, and has been involved in rdma too, so I'd > add him just for that. > > Some driver subsystems may be huge (eg media and sound), but I > don't know if they have issues. Mauro/Takashi? In the sound area, majority of commits come from Mark Brown's ASoC tree nowadays, and he should be included. Mark is already in your list, so we're covered pretty well by that. Do you plan it to be attached with some major conference, or as a stand-alone one? thanks, Takashi ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 19:50 ` Takashi Iwai @ 2017-04-18 20:13 ` Linus Torvalds 2017-04-18 20:21 ` Jiri Kosina ` (5 more replies) 0 siblings, 6 replies; 135+ messages in thread From: Linus Torvalds @ 2017-04-18 20:13 UTC (permalink / raw) To: Takashi Iwai Cc: Ingo Molnar, ksummit, Dave Airlie, Greg Kroah-Hartman, Doug Ledford, David Miller On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote: > On Tue, 18 Apr 2017 20:59:37 +0200, > Linus Torvalds wrote: >> >> Some driver subsystems may be huge (eg media and sound), but I >> don't know if they have issues. Mauro/Takashi? > > In the sound area, majority of commits come from Mark Brown's ASoC > tree nowadays, and he should be included. Mark is already in your > list, so we're covered pretty well by that. Ok. I don't know how many from that top-50 list we actually would be able to have. Not only do I think that we should try to limit it to maybe ~35 people (random number taken out of thin air, but feels small enough that people could basically just do it in a smaller room and keep things personal), but the list is just the 50 kernel maintainer side. And there's another important side to this if we can make it work: the *users* of the kernel. Notably I'd really like to have kernel leads from the main distros, ie Android, Fedora, Suse, Ubuntu. I think that when we talk about process pain points, we definitely need to have downstream involved. Greg is there with his stable maintainer hat on too, but he's still "ours". It would be really good to have whoever is in charge of the Android kernel there (not manager, but tech lead), and not make it a blame game, but really try to also talk about how we could perhaps bridge that gap somehow. I'm not sure who those people actually are, but I suspect this list contains people who can point to each tech lead.. I think it's Laura Abbott for Fedora, for example? > Do you plan it to be attached with some major conference, or as a > stand-alone one? Oh, I was just assuming people were aware of the kernel summit <-> maintainer summit thing. So this would be the maintainer side of the traditional kernel summit. This year it would be October in Prague, co-located with the European ELC / LinuxCon / OpenSourceSummit thing. Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:13 ` Linus Torvalds @ 2017-04-18 20:21 ` Jiri Kosina 2017-04-18 20:36 ` Takashi Iwai 2017-04-18 20:29 ` Takashi Iwai ` (4 subsequent siblings) 5 siblings, 1 reply; 135+ messages in thread From: Jiri Kosina @ 2017-04-18 20:21 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Greg Kroah-Hartman, David Miller, Dave Airlie, Doug Ledford, Ingo Molnar On Tue, 18 Apr 2017, Linus Torvalds wrote: > I'm not sure who those people actually are, but I suspect this list > contains people who can point to each tech lead.. I think it's Laura > Abbott for Fedora, for example? For SUSE, 3 out of 4 people who are actual internal branch maintainers (both enterprise and openSUSE products) are already included in your list, namely Takashi Iwai Michal Marek Jiri Kosina On top of that, the fourth maintainer is Jeff Mahoney We're maintaining quite a few codestreams in parallel (especially in the enterprise area), hence the split of responsibility. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:21 ` Jiri Kosina @ 2017-04-18 20:36 ` Takashi Iwai 0 siblings, 0 replies; 135+ messages in thread From: Takashi Iwai @ 2017-04-18 20:36 UTC (permalink / raw) To: Jiri Kosina Cc: ksummit, Greg Kroah-Hartman, David Miller, Dave Airlie, Doug Ledford, Ingo Molnar On Tue, 18 Apr 2017 22:21:31 +0200, Jiri Kosina wrote: > > On Tue, 18 Apr 2017, Linus Torvalds wrote: > > > I'm not sure who those people actually are, but I suspect this list > > contains people who can point to each tech lead.. I think it's Laura > > Abbott for Fedora, for example? > > For SUSE, 3 out of 4 people who are actual internal branch maintainers > (both enterprise and openSUSE products) are already included in your list, > namely > > Takashi Iwai > Michal Marek > Jiri Kosina > > On top of that, the fourth maintainer is > > Jeff Mahoney > > We're maintaining quite a few codestreams in parallel (especially in the > enterprise area), hence the split of responsibility. Yep, also we have the fifth maintainer, Jiri Slaby, for openSUSE Tumbleweed stable kernel branch. I forgot to mention, too. Takashi ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:13 ` Linus Torvalds 2017-04-18 20:21 ` Jiri Kosina @ 2017-04-18 20:29 ` Takashi Iwai 2017-04-18 20:33 ` Laura Abbott ` (3 subsequent siblings) 5 siblings, 0 replies; 135+ messages in thread From: Takashi Iwai @ 2017-04-18 20:29 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Greg Kroah-Hartman, Ingo Molnar, Dave Airlie, Doug Ledford, David Miller On Tue, 18 Apr 2017 22:13:37 +0200, Linus Torvalds wrote: > > On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote: > > On Tue, 18 Apr 2017 20:59:37 +0200, > > Linus Torvalds wrote: > >> > >> Some driver subsystems may be huge (eg media and sound), but I > >> don't know if they have issues. Mauro/Takashi? > > > > In the sound area, majority of commits come from Mark Brown's ASoC > > tree nowadays, and he should be included. Mark is already in your > > list, so we're covered pretty well by that. > > Ok. I don't know how many from that top-50 list we actually would be > able to have. > > Not only do I think that we should try to limit it to maybe ~35 people > (random number taken out of thin air, but feels small enough that > people could basically just do it in a smaller room and keep things > personal), but the list is just the 50 kernel maintainer side. > > And there's another important side to this if we can make it work: the > *users* of the kernel. Notably I'd really like to have kernel leads > from the main distros, ie Android, Fedora, Suse, Ubuntu. > > I think that when we talk about process pain points, we definitely > need to have downstream involved. Greg is there with his stable > maintainer hat on too, but he's still "ours". > > It would be really good to have whoever is in charge of the Android > kernel there (not manager, but tech lead), and not make it a blame > game, but really try to also talk about how we could perhaps bridge > that gap somehow. > > I'm not sure who those people actually are, but I suspect this list > contains people who can point to each tech lead.. I think it's Laura > Abbott for Fedora, for example? Well, if we think of the downstream, stable kernel maintainers play a big role. There is not only Greg, but there are a few others. For example, in the case of SUSE, the branch maintainers (Jiri Kosina, Michal Marek and me) are in your list, so it's good. But, we take fairly a big amount of changes through Jiri Slaby's 3.12.x stable tree for SLE12 (up to SP1). I guess other distros have such an aspect depending on the kernel versions they base on. > > Do you plan it to be attached with some major conference, or as a > > stand-alone one? > > Oh, I was just assuming people were aware of the kernel summit <-> > maintainer summit thing. Yeah, sorry, I noticed that later after my reply. A typical knee-jerk post. > So this would be the maintainer side of the traditional kernel summit. > > This year it would be October in Prague, co-located with the European > ELC / LinuxCon / OpenSourceSummit thing. Alright, thanks. Takashi ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:13 ` Linus Torvalds 2017-04-18 20:21 ` Jiri Kosina 2017-04-18 20:29 ` Takashi Iwai @ 2017-04-18 20:33 ` Laura Abbott 2017-04-18 21:15 ` Mauro Carvalho Chehab ` (2 subsequent siblings) 5 siblings, 0 replies; 135+ messages in thread From: Laura Abbott @ 2017-04-18 20:33 UTC (permalink / raw) To: Linus Torvalds, Takashi Iwai Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On 04/18/2017 01:13 PM, Linus Torvalds wrote: > On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote: >> On Tue, 18 Apr 2017 20:59:37 +0200, >> Linus Torvalds wrote: >>> >>> Some driver subsystems may be huge (eg media and sound), but I >>> don't know if they have issues. Mauro/Takashi? >> >> In the sound area, majority of commits come from Mark Brown's ASoC >> tree nowadays, and he should be included. Mark is already in your >> list, so we're covered pretty well by that. > > Ok. I don't know how many from that top-50 list we actually would be > able to have. > > Not only do I think that we should try to limit it to maybe ~35 people > (random number taken out of thin air, but feels small enough that > people could basically just do it in a smaller room and keep things > personal), but the list is just the 50 kernel maintainer side. > > And there's another important side to this if we can make it work: the > *users* of the kernel. Notably I'd really like to have kernel leads > from the main distros, ie Android, Fedora, Suse, Ubuntu. > > I think that when we talk about process pain points, we definitely > need to have downstream involved. Greg is there with his stable > maintainer hat on too, but he's still "ours". > > It would be really good to have whoever is in charge of the Android > kernel there (not manager, but tech lead), and not make it a blame > game, but really try to also talk about how we could perhaps bridge > that gap somehow. I think the Android lead is Rom Lemarchand, or he would know the best representative. > > I'm not sure who those people actually are, but I suspect this list > contains people who can point to each tech lead.. I think it's Laura > Abbott for Fedora, for example? > We're a team of two so there isn't really a tech lead per se. Justin Forbes is the other full time Fedora kernel maintainer. Laura ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:13 ` Linus Torvalds ` (2 preceding siblings ...) 2017-04-18 20:33 ` Laura Abbott @ 2017-04-18 21:15 ` Mauro Carvalho Chehab 2017-04-19 22:36 ` Jonathan Corbet 2017-04-19 15:37 ` Doug Ledford 2017-04-19 19:25 ` Laurent Pinchart 5 siblings, 1 reply; 135+ messages in thread From: Mauro Carvalho Chehab @ 2017-04-18 21:15 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Greg Kroah-Hartman, Ingo Molnar, Dave Airlie, Doug Ledford, David Miller Em Tue, 18 Apr 2017 13:13:37 -0700 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote: > > On Tue, 18 Apr 2017 20:59:37 +0200, > > Linus Torvalds wrote: > >> > >> Some driver subsystems may be huge (eg media and sound), but I > >> don't know if they have issues. Mauro/Takashi? On media side, I convert all pull requests I receive in a quilt tree, reviewing patch per patch. So, you won't see media sub-maintainers on a top-50 list based on comitters. Among sub-maintainers, Hans Verkuil is doing a great job sub-maintaining V4L2 drivers, with is a significant amount patches that come via my tree. With regards to issues, I'd say that everything that touches the process is relavant to media. Due to its nature, media devices are very complex, and interact with a lot of subsystems, like DT, arch, drm, input, network, i2c, staging, docs. So, I'm very interested on all discussions related to process. There is one particular issue that occurs to me, although I'm not sure if it would fit on the new "maintainer summit" format: it is related to how to group documentation. Also, this is actually Jon's call, but I suspect that he may want to hear comments from the others. Right now, all media documents are in a single book. There is an alternate model of splitting documentation on multiple documents, like, for example, grouping everything that is driver's API on a single document that covers multiple subsystems. While we could try to discuss this sort of thing via ML, I suspect that this is the sort of thing that would be better to discuss it on a forum with multiple maintainers, in order to see what would work best for the main subsystems. > > In the sound area, majority of commits come from Mark Brown's ASoC > > tree nowadays, and he should be included. Mark is already in your > > list, so we're covered pretty well by that. > > Ok. I don't know how many from that top-50 list we actually would be > able to have. > > Not only do I think that we should try to limit it to maybe ~35 people > (random number taken out of thin air, but feels small enough that > people could basically just do it in a smaller room and keep things > personal), but the list is just the 50 kernel maintainer side. > > And there's another important side to this if we can make it work: the > *users* of the kernel. Notably I'd really like to have kernel leads > from the main distros, ie Android, Fedora, Suse, Ubuntu. > > I think that when we talk about process pain points, we definitely > need to have downstream involved. Greg is there with his stable > maintainer hat on too, but he's still "ours". Yeah, having a few downstream maintainers there could be interesting, as we can get feedback about what should be improved in the process. Thanks, Mauro ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 21:15 ` Mauro Carvalho Chehab @ 2017-04-19 22:36 ` Jonathan Corbet 2017-04-19 22:41 ` Jiri Kosina 2017-04-20 11:25 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 135+ messages in thread From: Jonathan Corbet @ 2017-04-19 22:36 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: ksummit, Greg Kroah-Hartman, Ingo Molnar, Dave Airlie, Doug Ledford, David Miller On Tue, 18 Apr 2017 18:15:06 -0300 Mauro Carvalho Chehab <mchehab@infradead.org> wrote: > There is one particular issue that occurs to me, although I'm not sure > if it would fit on the new "maintainer summit" format: it is related > to how to group documentation. Also, this is actually Jon's call, but > I suspect that he may want to hear comments from the others. I could imagine talking about a few documentation issues, including interactions with the rest of the kernel. Who has responsibility for taking docs patches is often not clear, leading to multiple maintainers picking them up or conflicts between trees. We're also a ways into the Sphinx transition; I would be most curious to hear how others think it is going and whether/how the process should continue. jon ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 22:36 ` Jonathan Corbet @ 2017-04-19 22:41 ` Jiri Kosina 2017-04-19 23:36 ` Josh Triplett 2017-04-20 5:23 ` Christoph Hellwig 2017-04-20 11:25 ` Mauro Carvalho Chehab 1 sibling, 2 replies; 135+ messages in thread From: Jiri Kosina @ 2017-04-19 22:41 UTC (permalink / raw) To: Jonathan Corbet Cc: ksummit, David Miller, Dave Airlie, Greg Kroah-Hartman, Doug Ledford, Ingo Molnar On Wed, 19 Apr 2017, Jonathan Corbet wrote: > We're also a ways into the Sphinx transition; I would be most curious to > hear how others think it is going and whether/how the process should > continue. There is one piece of feedback I guess I can share right away on this -- I've heard so many complaints that Doc<tab>/kern<tab>-par<tab> completion stopped to yield Documentation/kernel-parameters.txt that it's not really funny any more :) -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 22:41 ` Jiri Kosina @ 2017-04-19 23:36 ` Josh Triplett 2017-04-19 23:51 ` Jiri Kosina 2017-04-20 5:23 ` Christoph Hellwig 1 sibling, 1 reply; 135+ messages in thread From: Josh Triplett @ 2017-04-19 23:36 UTC (permalink / raw) To: Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote: > On Wed, 19 Apr 2017, Jonathan Corbet wrote: > > > We're also a ways into the Sphinx transition; I would be most curious to > > hear how others think it is going and whether/how the process should > > continue. > > There is one piece of feedback I guess I can share right away on this -- > I've heard so many complaints that Doc<tab>/kern<tab>-par<tab> completion > stopped to yield Documentation/kernel-parameters.txt that it's not really > funny any more :) Is there any good reason we don't check in symlinks from the old location to the new location, considering that the new version remains readable in text form? ln -sf Documentation/process/coding-style.rst Documentation/CodingStyle ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt ... Commit 852d21ae1fcdf0e4de6b5bfa730d29cb013c7ff3 already did this for one such relocated file. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 23:36 ` Josh Triplett @ 2017-04-19 23:51 ` Jiri Kosina 2017-04-20 1:04 ` Josh Triplett 0 siblings, 1 reply; 135+ messages in thread From: Jiri Kosina @ 2017-04-19 23:51 UTC (permalink / raw) To: Josh Triplett Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Wed, 19 Apr 2017, Josh Triplett wrote: > ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt I think you just sort of demonstrated my point -- you got confused by this transition as well. Documentation/admin-guide/kernel-parameters.rst is rather useless. Documentation/admin-guide/kernel-parameters.txt is likely what you're looking for. This pattern can't be applied universally to other converted files though. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 23:51 ` Jiri Kosina @ 2017-04-20 1:04 ` Josh Triplett 2017-04-20 7:38 ` Jani Nikula 0 siblings, 1 reply; 135+ messages in thread From: Josh Triplett @ 2017-04-20 1:04 UTC (permalink / raw) To: Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Thu, Apr 20, 2017 at 01:51:26AM +0200, Jiri Kosina wrote: > On Wed, 19 Apr 2017, Josh Triplett wrote: > > ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt > > I think you just sort of demonstrated my point -- you got confused by this > transition as well. I looked at commit 9d85025b0418163fae079c9ba8f8445212de8568, which renamed Documentation/kernel-parameters.txt verbatim to Documentation/admin-guide/kernel-parameters.rst , saw that the file existed in the current kernel, and didn't look through the whole file to see that it just contained an include. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 1:04 ` Josh Triplett @ 2017-04-20 7:38 ` Jani Nikula 0 siblings, 0 replies; 135+ messages in thread From: Jani Nikula @ 2017-04-20 7:38 UTC (permalink / raw) To: Josh Triplett, Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Thu, 20 Apr 2017, Josh Triplett <josh@joshtriplett.org> wrote: > On Thu, Apr 20, 2017 at 01:51:26AM +0200, Jiri Kosina wrote: >> On Wed, 19 Apr 2017, Josh Triplett wrote: >> > ln -s Documentation/admin-guide/kernel-parameters.rst Documentation/kernel-parameters.txt >> >> I think you just sort of demonstrated my point -- you got confused by this >> transition as well. > > I looked at commit 9d85025b0418163fae079c9ba8f8445212de8568, which > renamed Documentation/kernel-parameters.txt verbatim to > Documentation/admin-guide/kernel-parameters.rst , saw that the file > existed in the current kernel, and didn't look through the whole file to > see that it just contained an include. Yes, unfortunately the 'make pdfdocs' build tripped over the long preformatted text block, and e52347bd66f6 ("Documentation/admin-guide: split the kernel parameter list to a separate file") was added as a stopgap workaround. Alas, there's no proper fix yet. :( BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 22:41 ` Jiri Kosina 2017-04-19 23:36 ` Josh Triplett @ 2017-04-20 5:23 ` Christoph Hellwig 2017-04-20 13:33 ` James Bottomley 1 sibling, 1 reply; 135+ messages in thread From: Christoph Hellwig @ 2017-04-20 5:23 UTC (permalink / raw) To: Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote: > There is one piece of feedback I guess I can share right away on this -- > I've heard so many complaints that Doc<tab>/kern<tab>-par<tab> completion > stopped to yield Documentation/kernel-parameters.txt that it's not really > funny any more :) Yeah. All this moving files around really messed up my workflows. Let's see if I'll be able to adjust eventually. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 5:23 ` Christoph Hellwig @ 2017-04-20 13:33 ` James Bottomley 2017-04-20 14:40 ` Alexey Dobriyan 2017-04-20 14:47 ` Jonathan Corbet 0 siblings, 2 replies; 135+ messages in thread From: James Bottomley @ 2017-04-20 13:33 UTC (permalink / raw) To: Christoph Hellwig, Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, 2017-04-19 at 22:23 -0700, Christoph Hellwig wrote: > On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote: > > There is one piece of feedback I guess I can share right away on > > this -- I've heard so many complaints that Doc<tab>/kern<tab> > > -par<tab> completion stopped to yield Documentation/kernel > > -parameters.txt that it's not really funny any more :) > > Yeah. All this moving files around really messed up my workflows. > Let's see if I'll be able to adjust eventually. Seconded. The one that trips me up the most is the uapi one ... I always forget that include/linux/X.h might have an include/uapi/linux/X.h counterpart which is where the structure I'm looking for actually is. I think it's worth discussing this. We accept a lot of patches because we can and because the change looks innocuous enough, but which don't actually have a tangible user visible benefit. Should we actually have a net benefit threshold test we apply? James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 13:33 ` James Bottomley @ 2017-04-20 14:40 ` Alexey Dobriyan 2017-04-20 14:52 ` Ingo Molnar 2017-04-20 14:47 ` Jonathan Corbet 1 sibling, 1 reply; 135+ messages in thread From: Alexey Dobriyan @ 2017-04-20 14:40 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Christoph Hellwig, Doug Ledford, David Miller On Thu, Apr 20, 2017 at 4:33 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Wed, 2017-04-19 at 22:23 -0700, Christoph Hellwig wrote: >> On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote: >> > There is one piece of feedback I guess I can share right away on >> > this -- I've heard so many complaints that Doc<tab>/kern<tab> >> > -par<tab> completion stopped to yield Documentation/kernel >> > -parameters.txt that it's not really funny any more :) >> >> Yeah. All this moving files around really messed up my workflows. >> Let's see if I'll be able to adjust eventually. > > Seconded. The one that trips me up the most is the uapi one ... I > always forget that include/linux/X.h might have an > include/uapi/linux/X.h counterpart which is where the structure I'm > looking for actually is. Let's not forget x86 master system call definition table movement. Just as finger memory is developed they move it again. And of course drivers/net directory structure explosion where drivers/net/e<TAB> doesn't work. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 14:40 ` Alexey Dobriyan @ 2017-04-20 14:52 ` Ingo Molnar 0 siblings, 0 replies; 135+ messages in thread From: Ingo Molnar @ 2017-04-20 14:52 UTC (permalink / raw) To: Alexey Dobriyan Cc: Christoph Hellwig, ksummit, Dave Airlie, Greg Kroah-Hartman, James Bottomley, Doug Ledford, David Miller * Alexey Dobriyan <adobriyan@gmail.com> wrote: > On Thu, Apr 20, 2017 at 4:33 PM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > On Wed, 2017-04-19 at 22:23 -0700, Christoph Hellwig wrote: > >> On Thu, Apr 20, 2017 at 12:41:04AM +0200, Jiri Kosina wrote: > >> > There is one piece of feedback I guess I can share right away on > >> > this -- I've heard so many complaints that Doc<tab>/kern<tab> > >> > -par<tab> completion stopped to yield Documentation/kernel > >> > -parameters.txt that it's not really funny any more :) > >> > >> Yeah. All this moving files around really messed up my workflows. > >> Let's see if I'll be able to adjust eventually. > > > > Seconded. The one that trips me up the most is the uapi one ... I > > always forget that include/linux/X.h might have an > > include/uapi/linux/X.h counterpart which is where the structure I'm > > looking for actually is. > > Let's not forget x86 master system call definition table movement. > Just as finger memory is developed they move it again. If you mean arch/x86/entry/syscalls/syscall_64.tbl, it was originally introduced 6 years ago as arch/x86/syscalls/syscall_64.tbl and moved _once_ to arch/x86/entry/syscalls/syscall_64.tbl. Same for arch/x86/syscalls/syscall_32.tbl, so I'm not sure what you are talking about here... Thanks, Ingo ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 13:33 ` James Bottomley 2017-04-20 14:40 ` Alexey Dobriyan @ 2017-04-20 14:47 ` Jonathan Corbet 2017-04-20 15:34 ` James Bottomley 1 sibling, 1 reply; 135+ messages in thread From: Jonathan Corbet @ 2017-04-20 14:47 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Christoph Hellwig, Doug Ledford, David Miller On Thu, 20 Apr 2017 06:33:58 -0700 James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > I think it's worth discussing this. We accept a lot of patches because > we can and because the change looks innocuous enough, but which don't > actually have a tangible user visible benefit. Should we actually have > a net benefit threshold test we apply? With regard to the documentation patches, the intended tangible user-visible benefit is to turn a jumbled mess of a documentation directory into a set of coherent manuals that are aimed at and readily accessible to our different audiences (kernel developers, system administrators, application developers, etc. as appropriate). If we had always tossed the SCSI subsystem source into a single directory along with SCTP, user-mode Linux, perf, half of the TTY drivers, and all filesystems written before the second Bush administration, it would certainly make for easier muscle-memory access for those of us who think back nostalgically to installing from floppies. But for some strange reason we don't do that. When code needs refactoring, we do so - when, as you said, there is a tangible benefit. The same applies to directory organization. Though that may not apply to Documentation/ since we never really got around to an original factoring to refactor. Anyway, you can see why I raised the issue. I think that this process is improving the documentation, making it more accessible, and making more people interested in improving it. But I have my hands plenty full of other things and, if this work is really swimming against the current, it would be good to know. jon ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 14:47 ` Jonathan Corbet @ 2017-04-20 15:34 ` James Bottomley 0 siblings, 0 replies; 135+ messages in thread From: James Bottomley @ 2017-04-20 15:34 UTC (permalink / raw) To: Jonathan Corbet Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Christoph Hellwig, Doug Ledford, Ingo Molnar On Thu, 2017-04-20 at 08:47 -0600, Jonathan Corbet wrote: > On Thu, 20 Apr 2017 06:33:58 -0700 > James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > I think it's worth discussing this. We accept a lot of patches > > because we can and because the change looks innocuous enough, but > > which don't actually have a tangible user visible benefit. Should > > we actually have a net benefit threshold test we apply? > > With regard to the documentation patches, the intended tangible > user-visible benefit is to turn a jumbled mess of a documentation > directory into a set of coherent manuals that are aimed at and > readily accessible to our different audiences (kernel developers, > system administrators, application developers, etc. as appropriate). I'm not saying don't do it, I'm staying understand the cost vs benefit before doing it. > If we had always tossed the SCSI subsystem source into a single > directory along with SCTP, user-mode Linux, perf, half of the TTY > drivers, and all filesystems written before the second Bush > administration, it would certainly make for easier muscle-memory > access for those of us who think back nostalgically to installing > from floppies. But for some strange reason we don't do that. I'm also not saying do a flat tree. I am saying putting things in the right place ab initio and then having a reasonably high barrier for moving it has value. > When code needs refactoring, we do so - when, as you said, there is a > tangible benefit. Right, I think we've been quite good at the refactor net benefit tests ... mostly, I think, because refactoring is a lot of work and a lot of argument to get it accepted so people think very carefully before they do it. It is self supplying on the net benefit test ... I think we have certain actions which aren't so self supplying in this regard. Ideally, everything would be like this: the level of difficulty in doing something would be directly proportional to the amount of thought you should put into it. However, the world is not mostly structured like this hence the question about a net benefit test which would raise the barrier. > The same applies to directory organization. Though that may not > apply to Documentation/ since we never really got around > to an original factoring to refactor. > > Anyway, you can see why I raised the issue. I think that this > process is improving the documentation, making it more accessible, > and making more people interested in improving it. But I have my > hands plenty full of other things and, if this work is really > swimming against the current, it would be good to know. I'd prefer it if the summit didn't become a star chamber where we re -run past decisions. However, I think the process question of how (or whether) we should add process barriers for certain actions is a useful one. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 22:36 ` Jonathan Corbet 2017-04-19 22:41 ` Jiri Kosina @ 2017-04-20 11:25 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 135+ messages in thread From: Mauro Carvalho Chehab @ 2017-04-20 11:25 UTC (permalink / raw) To: Jonathan Corbet Cc: ksummit, Greg Kroah-Hartman, Ingo Molnar, Dave Airlie, Doug Ledford, David Miller Em Wed, 19 Apr 2017 16:36:36 -0600 Jonathan Corbet <corbet@lwn.net> escreveu: > On Tue, 18 Apr 2017 18:15:06 -0300 > Mauro Carvalho Chehab <mchehab@infradead.org> wrote: > > > There is one particular issue that occurs to me, although I'm not sure > > if it would fit on the new "maintainer summit" format: it is related > > to how to group documentation. Also, this is actually Jon's call, but > > I suspect that he may want to hear comments from the others. > > I could imagine talking about a few documentation issues, including > interactions with the rest of the kernel. Who has responsibility for > taking docs patches is often not clear, leading to multiple maintainers > picking them up or conflicts between trees. I suspect that conflicts are hard to avoid, as often patch series need to touch both code and Documentation/. I guess keeping the MAINTAINERS updated to reflect who is responsible for each file under Documentation is one important step to minimize conflicts. Btw, that's one of the reasons why I believe that one book per subsystem would work better than spreading the subsystem documentation among several different books: once such book is added at the main Documentation/index.rst and Documentation/conf.py, the subsystem maintainer can take care of all documentation patches for such book without risking to cause conflicts with other trees. Thanks, Mauro ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:13 ` Linus Torvalds ` (3 preceding siblings ...) 2017-04-18 21:15 ` Mauro Carvalho Chehab @ 2017-04-19 15:37 ` Doug Ledford 2017-04-19 16:18 ` Linus Torvalds 2017-04-19 19:25 ` Laurent Pinchart 5 siblings, 1 reply; 135+ messages in thread From: Doug Ledford @ 2017-04-19 15:37 UTC (permalink / raw) To: Linus Torvalds, Takashi Iwai Cc: Ingo Molnar, ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller [-- Attachment #1.1: Type: text/plain, Size: 3101 bytes --] On 4/18/2017 4:13 PM, Linus Torvalds wrote: > On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote: >> On Tue, 18 Apr 2017 20:59:37 +0200, >> Linus Torvalds wrote: >>> >>> Some driver subsystems may be huge (eg media and sound), but I >>> don't know if they have issues. Mauro/Takashi? >> >> In the sound area, majority of commits come from Mark Brown's ASoC >> tree nowadays, and he should be included. Mark is already in your >> list, so we're covered pretty well by that. > > Ok. I don't know how many from that top-50 list we actually would be > able to have. > > Not only do I think that we should try to limit it to maybe ~35 people > (random number taken out of thin air, but feels small enough that > people could basically just do it in a smaller room and keep things > personal), but the list is just the 50 kernel maintainer side. > > And there's another important side to this if we can make it work: the > *users* of the kernel. Notably I'd really like to have kernel leads > from the main distros, ie Android, Fedora, Suse, Ubuntu. > > I think that when we talk about process pain points, we definitely > need to have downstream involved. Greg is there with his stable > maintainer hat on too, but he's still "ours". > > It would be really good to have whoever is in charge of the Android > kernel there (not manager, but tech lead), and not make it a blame > game, but really try to also talk about how we could perhaps bridge > that gap somehow. > > I'm not sure who those people actually are, but I suspect this list > contains people who can point to each tech lead.. I think it's Laura > Abbott for Fedora, for example? There really is no pain point for Fedora. They take a very simple approach: in rawhide, they pull latest git once you hit the -rc cycles and build it, otherwise it's the latest released kernel; in actual releases, they pull stable tree point releases as they are released (not long term stable, they upgrade to a new stable tree fairly regularly). They really don't do much in the way of having to integrate changes into their kernel (intentionally), it's just a constant rolling update game using newer and newer tarballs. So, the pain is not in Fedora, it's in RHEL. What we do there is so totally different from Fedora and hurts so bad as a developer...but I don't know if you really care to even talk about that at the summit since, to be fair, it's largely a consequence of our business model. >> Do you plan it to be attached with some major conference, or as a >> stand-alone one? > > Oh, I was just assuming people were aware of the kernel summit <-> > maintainer summit thing. > > So this would be the maintainer side of the traditional kernel summit. > > This year it would be October in Prague, co-located with the European > ELC / LinuxCon / OpenSourceSummit thing. > > Linus > -- Doug Ledford <dledford@redhat.com> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 15:37 ` Doug Ledford @ 2017-04-19 16:18 ` Linus Torvalds 2017-04-19 16:24 ` Doug Ledford ` (3 more replies) 0 siblings, 4 replies; 135+ messages in thread From: Linus Torvalds @ 2017-04-19 16:18 UTC (permalink / raw) To: Doug Ledford Cc: ksummit, Greg Kroah-Hartman, Ingo Molnar, Dave Airlie, David Miller On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote: > On 4/18/2017 4:13 PM, Linus Torvalds wrote: >> >> I'm not sure who those people actually are, but I suspect this list >> contains people who can point to each tech lead.. I think it's Laura >> Abbott for Fedora, for example? > > There really is no pain point for Fedora. They take a very simple > approach: in rawhide, they pull latest git once you hit the -rc cycles > and build it, otherwise it's the latest released kernel; in actual > releases, they pull stable tree point releases as they are released (not > long term stable, they upgrade to a new stable tree fairly regularly). > They really don't do much in the way of having to integrate changes into > their kernel (intentionally), it's just a constant rolling update game > using newer and newer tarballs. So, the pain is not in Fedora, it's in > RHEL. What we do there is so totally different from Fedora and hurts so > bad as a developer...but I don't know if you really care to even talk > about that at the summit since, to be fair, it's largely a consequence > of our business model. Yeah, I don't think we can do much about distros that intentionally want to stay behind and backport. Admittedly Android seems to be very much in that camp too, but I'd at least want to talk to them more. RHEL I feel knows what it's doing and isn't causing the kinds of issues Android is anyway. That said, even with Fedora I think Laura was at the KS last year, and did talk about what she sees as the stable kernel process. So Fedora may not be a "painpoint", but may well be relevant for the "meet with people and talk about process issues once a year". Of course, if it really is a question of "we have no problems and no reason to even be there" for Fedora, then that's one (or two) less people to worry about ;) Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 16:18 ` Linus Torvalds @ 2017-04-19 16:24 ` Doug Ledford 2017-04-19 18:11 ` Justin Forbes ` (2 subsequent siblings) 3 siblings, 0 replies; 135+ messages in thread From: Doug Ledford @ 2017-04-19 16:24 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Greg Kroah-Hartman, Ingo Molnar, Dave Airlie, David Miller [-- Attachment #1.1: Type: text/plain, Size: 2284 bytes --] On 4/19/2017 12:18 PM, Linus Torvalds wrote: > On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote: >> On 4/18/2017 4:13 PM, Linus Torvalds wrote: >>> >>> I'm not sure who those people actually are, but I suspect this list >>> contains people who can point to each tech lead.. I think it's Laura >>> Abbott for Fedora, for example? >> >> There really is no pain point for Fedora. They take a very simple >> approach: in rawhide, they pull latest git once you hit the -rc cycles >> and build it, otherwise it's the latest released kernel; in actual >> releases, they pull stable tree point releases as they are released (not >> long term stable, they upgrade to a new stable tree fairly regularly). >> They really don't do much in the way of having to integrate changes into >> their kernel (intentionally), it's just a constant rolling update game >> using newer and newer tarballs. So, the pain is not in Fedora, it's in >> RHEL. What we do there is so totally different from Fedora and hurts so >> bad as a developer...but I don't know if you really care to even talk >> about that at the summit since, to be fair, it's largely a consequence >> of our business model. > > Yeah, I don't think we can do much about distros that intentionally > want to stay behind and backport. Admittedly Android seems to be very > much in that camp too, but I'd at least want to talk to them more. > RHEL I feel knows what it's doing and isn't causing the kinds of > issues Android is anyway. > > That said, even with Fedora I think Laura was at the KS last year, and > did talk about what she sees as the stable kernel process. So Fedora > may not be a "painpoint", but may well be relevant for the "meet with > people and talk about process issues once a year". Entirely true. And I probably shouldn't have said there is no pain point for Fedora, because I shouldn't have put words in her mouth anyway. I would *expect* there is no pain point given their model (and I've not seen the internal email discussions we see around our RHEL kernels), but I can't speak beyond that. -- Doug Ledford <dledford@redhat.com> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 16:18 ` Linus Torvalds 2017-04-19 16:24 ` Doug Ledford @ 2017-04-19 18:11 ` Justin Forbes 2017-04-19 21:52 ` Geert Uytterhoeven 2017-04-19 18:21 ` Laura Abbott 2017-04-20 8:17 ` Jani Nikula 3 siblings, 1 reply; 135+ messages in thread From: Justin Forbes @ 2017-04-19 18:11 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 2668 bytes --] On Wed, Apr 19, 2017 at 11:18 AM, Linus Torvalds < torvalds@linux-foundation.org> wrote: > On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote: > > On 4/18/2017 4:13 PM, Linus Torvalds wrote: > >> > >> I'm not sure who those people actually are, but I suspect this list > >> contains people who can point to each tech lead.. I think it's Laura > >> Abbott for Fedora, for example? > > > > There really is no pain point for Fedora. They take a very simple > > approach: in rawhide, they pull latest git once you hit the -rc cycles > > and build it, otherwise it's the latest released kernel; in actual > > releases, they pull stable tree point releases as they are released (not > > long term stable, they upgrade to a new stable tree fairly regularly). > > They really don't do much in the way of having to integrate changes into > > their kernel (intentionally), it's just a constant rolling update game > > using newer and newer tarballs. So, the pain is not in Fedora, it's in > > RHEL. What we do there is so totally different from Fedora and hurts so > > bad as a developer...but I don't know if you really care to even talk > > about that at the summit since, to be fair, it's largely a consequence > > of our business model. > > There are certainly pain points in Fedora, very much related to this model. The approach is simple, the implementation could be better. Our pain points are just very different from the RHEL pain points. For instance, while stable has been a great success over the years, the policy is no fixes in stable until they are in head. Unfortunately a lot of simple fixes end up in queued in maintainer trees for -next and never end up in head until the next merge window. I don't know what the answer here is, changing the stable policy in this regard doesn't seem like the best solution. > Yeah, I don't think we can do much about distros that intentionally > want to stay behind and backport. Admittedly Android seems to be very > much in that camp too, but I'd at least want to talk to them more. > RHEL I feel knows what it's doing and isn't causing the kinds of > issues Android is anyway. > > That said, even with Fedora I think Laura was at the KS last year, and > did talk about what she sees as the stable kernel process. So Fedora > may not be a "painpoint", but may well be relevant for the "meet with > people and talk about process issues once a year". > > Of course, if it really is a question of "we have no problems and no > reason to even be there" for Fedora, then that's one (or two) less > people to worry about ;) Laura is a good candidate to discuss the Fedora pain points. Justin [-- Attachment #2: Type: text/html, Size: 3504 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 18:11 ` Justin Forbes @ 2017-04-19 21:52 ` Geert Uytterhoeven 0 siblings, 0 replies; 135+ messages in thread From: Geert Uytterhoeven @ 2017-04-19 21:52 UTC (permalink / raw) To: Justin Forbes Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller Hi Justin, On Wed, Apr 19, 2017 at 8:11 PM, Justin Forbes <jforbes@redhat.com> wrote: > For instance, while stable has been a great success over the years, the > policy is no fixes in stable until they are in head. Unfortunately a lot of > simple fixes end up in queued in maintainer trees for -next and never end up > in head until the next merge window. I don't know what the answer here is, > changing the stable policy in this regard doesn't seem like the best > solution. I think this has been discussed before: it's about finding a good balance between fixing bugs, and making sure the fixes don't cause regressions. Even with the policy of no fixes in stable until they are in head, we sometimes end up with fixes in stable that do introduce regressions. I believe someone has statistics about that? 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] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 16:18 ` Linus Torvalds 2017-04-19 16:24 ` Doug Ledford 2017-04-19 18:11 ` Justin Forbes @ 2017-04-19 18:21 ` Laura Abbott 2017-04-20 8:31 ` Jani Nikula 2017-04-20 8:17 ` Jani Nikula 3 siblings, 1 reply; 135+ messages in thread From: Laura Abbott @ 2017-04-19 18:21 UTC (permalink / raw) To: Linus Torvalds, Doug Ledford Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, ksummit, David Miller On 04/19/2017 09:18 AM, Linus Torvalds wrote: > On Wed, Apr 19, 2017 at 8:37 AM, Doug Ledford <dledford@redhat.com> wrote: >> On 4/18/2017 4:13 PM, Linus Torvalds wrote: >>> >>> I'm not sure who those people actually are, but I suspect this list >>> contains people who can point to each tech lead.. I think it's Laura >>> Abbott for Fedora, for example? >> >> There really is no pain point for Fedora. They take a very simple >> approach: in rawhide, they pull latest git once you hit the -rc cycles >> and build it, otherwise it's the latest released kernel; in actual >> releases, they pull stable tree point releases as they are released (not >> long term stable, they upgrade to a new stable tree fairly regularly). >> They really don't do much in the way of having to integrate changes into >> their kernel (intentionally), it's just a constant rolling update game >> using newer and newer tarballs. So, the pain is not in Fedora, it's in >> RHEL. What we do there is so totally different from Fedora and hurts so >> bad as a developer...but I don't know if you really care to even talk >> about that at the summit since, to be fair, it's largely a consequence >> of our business model. > > Yeah, I don't think we can do much about distros that intentionally > want to stay behind and backport. Admittedly Android seems to be very > much in that camp too, but I'd at least want to talk to them more. > RHEL I feel knows what it's doing and isn't causing the kinds of > issues Android is anyway. > > That said, even with Fedora I think Laura was at the KS last year, and > did talk about what she sees as the stable kernel process. So Fedora > may not be a "painpoint", but may well be relevant for the "meet with > people and talk about process issues once a year". > > Of course, if it really is a question of "we have no problems and no > reason to even be there" for Fedora, then that's one (or two) less > people to worry about ;) > > Linus I wouldn't say we have no problems or pain points. It's a different kind of paint point than what RHEL deals with. The building and integration is simpler but the frequent updates can be difficult for end users who are not experienced kernel developers. I brought up bug reporting last year and I still consider that to be an issue this year. A good example is https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really make progress until I sent out a separate e-mail thread summarizing the bisections people did. There are only 2 of us on Fedora so having to guide users along on every bug doesn't scale well. The irregular timing of stable updates also makes it difficult to give an answer to users who want to know "when will this be fixed". Thanks, Laura ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 18:21 ` Laura Abbott @ 2017-04-20 8:31 ` Jani Nikula 2017-04-20 12:35 ` Mark Brown 2017-04-21 8:41 ` Alexandre Belloni 0 siblings, 2 replies; 135+ messages in thread From: Jani Nikula @ 2017-04-20 8:31 UTC (permalink / raw) To: Laura Abbott, Linus Torvalds, Doug Ledford Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, ksummit, David Miller On Wed, 19 Apr 2017, Laura Abbott <labbott@redhat.com> wrote: > I brought up bug reporting last year and I still consider that to be > an issue this year. A good example is > https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really > make progress until I sent out a separate e-mail thread summarizing > the bisections people did. The service level at https://bugzilla.kernel.org heavily depends on the subsystem/driver. Some maintainers just ignore it completely. MAINTAINERS now has the "B:" entry to document where maintainers want bugs reported, and I'd like to see more maintainers document their preferences there. Would be great to have bugzilla inform the bug reporters if some component is likely to be ignored, based on the info in MAINTAINERS, but I suppose that's a bunch of manual work unlikely to happen. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 8:31 ` Jani Nikula @ 2017-04-20 12:35 ` Mark Brown 2017-04-20 13:01 ` Jani Nikula 2017-04-21 8:41 ` Alexandre Belloni 1 sibling, 1 reply; 135+ messages in thread From: Mark Brown @ 2017-04-20 12:35 UTC (permalink / raw) To: Jani Nikula Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 388 bytes --] On Thu, Apr 20, 2017 at 11:31:31AM +0300, Jani Nikula wrote: > subsystem/driver. Some maintainers just ignore it completely. > MAINTAINERS now has the "B:" entry to document where maintainers want > bugs reported, and I'd like to see more maintainers document their > preferences there. I'd expect that a large proportion of people are assuming the default is to report it to the list. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 12:35 ` Mark Brown @ 2017-04-20 13:01 ` Jani Nikula 0 siblings, 0 replies; 135+ messages in thread From: Jani Nikula @ 2017-04-20 13:01 UTC (permalink / raw) To: Mark Brown Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Thu, 20 Apr 2017, Mark Brown <broonie@kernel.org> wrote: > On Thu, Apr 20, 2017 at 11:31:31AM +0300, Jani Nikula wrote: > >> subsystem/driver. Some maintainers just ignore it completely. >> MAINTAINERS now has the "B:" entry to document where maintainers want >> bugs reported, and I'd like to see more maintainers document their >> preferences there. > > I'd expect that a large proportion of people are assuming the default is > to report it to the list. Seems like the right thing to do is to better document the expectations in Documentation/admin-guide/reporting-bugs.rst, and then point MAINTAINERS and, more importantly, [1] and [2] to that. BR, Jani. [1] https://bugzilla.kernel.org/page.cgi?id=faq.html [2] https://bugzilla.kernel.org/page.cgi?id=bug-writing.html -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 8:31 ` Jani Nikula 2017-04-20 12:35 ` Mark Brown @ 2017-04-21 8:41 ` Alexandre Belloni 2017-04-21 14:46 ` David Miller 1 sibling, 1 reply; 135+ messages in thread From: Alexandre Belloni @ 2017-04-21 8:41 UTC (permalink / raw) To: Jani Nikula Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On 20/04/2017 at 11:31:31 +0300, Jani Nikula wrote: > On Wed, 19 Apr 2017, Laura Abbott <labbott@redhat.com> wrote: > > I brought up bug reporting last year and I still consider that to be > > an issue this year. A good example is > > https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really > > make progress until I sent out a separate e-mail thread summarizing > > the bisections people did. > > The service level at https://bugzilla.kernel.org heavily depends on the > subsystem/driver. Some maintainers just ignore it completely. > MAINTAINERS now has the "B:" entry to document where maintainers want > bugs reported, and I'd like to see more maintainers document their > preferences there. > I think that addition has not been noticed by many maintainers and that is actually one of my pain point. I feel like that kind of changes that are relevant for all the maintainers are not advertised enough but I also realize you probably don't want to Cc: every maintainer on your patch. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 8:41 ` Alexandre Belloni @ 2017-04-21 14:46 ` David Miller 0 siblings, 0 replies; 135+ messages in thread From: David Miller @ 2017-04-21 14:46 UTC (permalink / raw) To: alexandre.belloni; +Cc: ksummit-discuss, gregkh, airlied, dledford, mingo From: Alexandre Belloni <alexandre.belloni@free-electrons.com> Date: Fri, 21 Apr 2017 10:41:55 +0200 > On 20/04/2017 at 11:31:31 +0300, Jani Nikula wrote: >> On Wed, 19 Apr 2017, Laura Abbott <labbott@redhat.com> wrote: >> > I brought up bug reporting last year and I still consider that to be >> > an issue this year. A good example is >> > https://bugzilla.kernel.org/show_bug.cgi?id=194911 which didn't really >> > make progress until I sent out a separate e-mail thread summarizing >> > the bisections people did. >> >> The service level at https://bugzilla.kernel.org heavily depends on the >> subsystem/driver. Some maintainers just ignore it completely. >> MAINTAINERS now has the "B:" entry to document where maintainers want >> bugs reported, and I'd like to see more maintainers document their >> preferences there. >> > > I think that addition has not been noticed by many maintainers and that > is actually one of my pain point. Indeed, I was completely unaware of this. Now that I am I have added an appropriate entry for the networking. Thanks. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 16:18 ` Linus Torvalds ` (2 preceding siblings ...) 2017-04-19 18:21 ` Laura Abbott @ 2017-04-20 8:17 ` Jani Nikula 2017-04-20 10:59 ` Greg Kroah-Hartman 3 siblings, 1 reply; 135+ messages in thread From: Jani Nikula @ 2017-04-20 8:17 UTC (permalink / raw) To: Linus Torvalds, Doug Ledford Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, ksummit, David Miller On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote: > Yeah, I don't think we can do much about distros that intentionally > want to stay behind and backport. /me looks at https://www.kernel.org/ 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm is based on a five years old release. I just think the multitude of longterm kernels are sending a message that it's perfectly fine to stay behind. Don't get me wrong, I know why they are there, but I still think in the past the focus on encouraging to always use the latest stable kernel was stronger. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 8:17 ` Jani Nikula @ 2017-04-20 10:59 ` Greg Kroah-Hartman 2017-04-20 12:22 ` Jani Nikula 2017-04-20 14:49 ` Mark Brown 0 siblings, 2 replies; 135+ messages in thread From: Greg Kroah-Hartman @ 2017-04-20 10:59 UTC (permalink / raw) To: Jani Nikula; +Cc: ksummit, Dave Airlie, David Miller, Doug Ledford, Ingo Molnar On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote: > On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Yeah, I don't think we can do much about distros that intentionally > > want to stay behind and backport. > > /me looks at https://www.kernel.org/ > > 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm > is based on a five years old release. That 5 year old kernel is due to Debian's looney release schedule, go take it up with them :) > I just think the multitude of longterm kernels are sending a message > that it's perfectly fine to stay behind. Don't get me wrong, I know why > they are there, but I still think in the past the focus on encouraging > to always use the latest stable kernel was stronger. And how do you suggest that we do that any more than we currently do? (i.e. I go around and talk to companies all the time about this issue, did a tour of Asia last month, and will be talking to some US-based companies next month.) As you say, you know why they are there, so why is that not a valid reason in itself? :) And you will note (although everyone seems to ignore it), that we are now only adding 1 new LTS kernel a year, and have been for the past few years, in order to cut down on the proliferation we had 3-4 years back. thanks, greg k-h ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 10:59 ` Greg Kroah-Hartman @ 2017-04-20 12:22 ` Jani Nikula 2017-04-20 13:03 ` Greg Kroah-Hartman 2017-04-20 14:49 ` Mark Brown 1 sibling, 1 reply; 135+ messages in thread From: Jani Nikula @ 2017-04-20 12:22 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: ksummit, Dave Airlie, David Miller, Doug Ledford, Ingo Molnar On Thu, 20 Apr 2017, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote: >> On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote: >> > Yeah, I don't think we can do much about distros that intentionally >> > want to stay behind and backport. >> >> /me looks at https://www.kernel.org/ >> >> 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm >> is based on a five years old release. > > That 5 year old kernel is due to Debian's looney release schedule, go > take it up with them :) > >> I just think the multitude of longterm kernels are sending a message >> that it's perfectly fine to stay behind. Don't get me wrong, I know why >> they are there, but I still think in the past the focus on encouraging >> to always use the latest stable kernel was stronger. > > And how do you suggest that we do that any more than we currently do? > (i.e. I go around and talk to companies all the time about this issue, > did a tour of Asia last month, and will be talking to some US-based > companies next month.) > > As you say, you know why they are there, so why is that not a valid > reason in itself? :) Well, I'm just saying it's a double edged sword. Accommodating the longterms says it's okay to rely on them, but then you go around the world telling people they shouldn't do that anyway. It's a tradeoff. Or maybe you just like traveling? ;) > And you will note (although everyone seems to ignore it), that we are > now only adding 1 new LTS kernel a year, and have been for the past few > years, in order to cut down on the proliferation we had 3-4 years back. I think that's a step in the right direction. How about having a shorter lifetime too, despite "longterm"? Of course that would conflict with what the distros are doing, and this may not be a popular view, but I'm wondering if it's overall a net positive to give an appearance of kernel.org endorsing all these ancient kernels? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 12:22 ` Jani Nikula @ 2017-04-20 13:03 ` Greg Kroah-Hartman 0 siblings, 0 replies; 135+ messages in thread From: Greg Kroah-Hartman @ 2017-04-20 13:03 UTC (permalink / raw) To: Jani Nikula; +Cc: ksummit, Dave Airlie, David Miller, Doug Ledford, Ingo Molnar On Thu, Apr 20, 2017 at 03:22:26PM +0300, Jani Nikula wrote: > On Thu, 20 Apr 2017, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote: > >> On Wed, 19 Apr 2017, Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> > Yeah, I don't think we can do much about distros that intentionally > >> > want to stay behind and backport. > >> > >> /me looks at https://www.kernel.org/ > >> > >> 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm > >> is based on a five years old release. > > > > That 5 year old kernel is due to Debian's looney release schedule, go > > take it up with them :) > > > >> I just think the multitude of longterm kernels are sending a message > >> that it's perfectly fine to stay behind. Don't get me wrong, I know why > >> they are there, but I still think in the past the focus on encouraging > >> to always use the latest stable kernel was stronger. > > > > And how do you suggest that we do that any more than we currently do? > > (i.e. I go around and talk to companies all the time about this issue, > > did a tour of Asia last month, and will be talking to some US-based > > companies next month.) > > > > As you say, you know why they are there, so why is that not a valid > > reason in itself? :) > > Well, I'm just saying it's a double edged sword. Accommodating the > longterms says it's okay to rely on them, but then you go around the > world telling people they shouldn't do that anyway. It's a tradeoff. > > Or maybe you just like traveling? ;) No, I don't like traveling :) And I tell people to rely on these kernels instead of trying to do it on their own, as they always get it wrong when they do not use a longterm kernel (they were going to only stick with one kernel release anyway). I tell people to pick the latest LTS for their product, and use that, and update constantly. Even better, if their SoC vendor doesn't add 2-3 million lines of code to their kernel, use the latest kernel.org release from Linus. But SoC vendors who don't do that are very few these days, so lots of my work is to try to cut that huge diff down. But getting rid of that diff is going to take a long time, or major customer disatisfaction/change, which I'm also trying to force. Otherwise the SoC vendor doesn't really care (as is evident by the 3 million line diff...) > > And you will note (although everyone seems to ignore it), that we are > > now only adding 1 new LTS kernel a year, and have been for the past few > > years, in order to cut down on the proliferation we had 3-4 years back. > > I think that's a step in the right direction. How about having a shorter > lifetime too, despite "longterm"? Of course that would conflict with > what the distros are doing, and this may not be a popular view, but I'm > wondering if it's overall a net positive to give an appearance of > kernel.org endorsing all these ancient kernels? Why is longer lifetimes bad? If the developer wants to do the work, that's fine. For lots of users, they have to stay at a specific kernel release due to (again) their horrid SoC vendor. Heck, I've even offered to forward port some SoC trees to newer kernels, and had the SoC vendor turn me down because they don't want anyone to get the idea that it would even be possible to do! So some users are stuck at these older kernels, supporting them with a stream of good bugfixes is essential to ensure that their devices are secure and work well over time. That's a valuable thing for them and a good reason for them to use Linux. It's not a black/white issue here, as you well know, it's a large ecosystem full of different groups pulling different ways. I'll always push for people to use newer kernels, and age-out older ones, and the new hardware treadmill supports that quite well. Combined with educating and helping companies merge stuff upstream, it can get better, and is. Look at how bad it used to be just 3 years ago :) thanks, greg k-h ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 10:59 ` Greg Kroah-Hartman 2017-04-20 12:22 ` Jani Nikula @ 2017-04-20 14:49 ` Mark Brown 1 sibling, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-20 14:49 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: ksummit, Ingo Molnar, Dave Airlie, Doug Ledford, David Miller [-- Attachment #1: Type: text/plain, Size: 1384 bytes --] On Thu, Apr 20, 2017 at 12:59:33PM +0200, Greg Kroah-Hartman wrote: > On Thu, Apr 20, 2017 at 11:17:18AM +0300, Jani Nikula wrote: > > 1 stable, 8 longterm, and 1 eol'd longterm kernels. The oldest longterm > > is based on a five years old release. > That 5 year old kernel is due to Debian's looney release schedule, go > take it up with them :) A combination of release schedule and lack of desire to update kernels mid release. > > I just think the multitude of longterm kernels are sending a message > > that it's perfectly fine to stay behind. Don't get me wrong, I know why > > they are there, but I still think in the past the focus on encouraging > > to always use the latest stable kernel was stronger. > And how do you suggest that we do that any more than we currently do? > (i.e. I go around and talk to companies all the time about this issue, > did a tour of Asia last month, and will be talking to some US-based > companies next month.) Honestly at this point I'm not even sure how much of an issue it is with the idea that people should update - as far as I can tell the main problems are similar to the things keeping the enterprise distros from upgrading, not wanting to introduce large change in something that's already production. I'm not sure we have any good answers there really other than gradually getting through the technical debt with upstreaming. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:13 ` Linus Torvalds ` (4 preceding siblings ...) 2017-04-19 15:37 ` Doug Ledford @ 2017-04-19 19:25 ` Laurent Pinchart 2017-04-19 19:40 ` Linus Torvalds 5 siblings, 1 reply; 135+ messages in thread From: Laurent Pinchart @ 2017-04-19 19:25 UTC (permalink / raw) To: ksummit-discuss Cc: Greg Kroah-Hartman, David Miller, Dave Airlie, Doug Ledford, Ingo Molnar Hi Linus, On Tuesday 18 Apr 2017 13:13:37 Linus Torvalds wrote: > On Tue, Apr 18, 2017 at 12:50 PM, Takashi Iwai <tiwai@suse.de> wrote: > > On Tue, 18 Apr 2017 20:59:37 +0200, Linus Torvalds wrote: > >> Some driver subsystems may be huge (eg media and sound), but I > >> don't know if they have issues. Mauro/Takashi? > > > > In the sound area, majority of commits come from Mark Brown's ASoC > > tree nowadays, and he should be included. Mark is already in your > > list, so we're covered pretty well by that. > > Ok. I don't know how many from that top-50 list we actually would be > able to have. > > Not only do I think that we should try to limit it to maybe ~35 people > (random number taken out of thin air, but feels small enough that > people could basically just do it in a smaller room and keep things > personal), but the list is just the 50 kernel maintainer side. > > And there's another important side to this if we can make it work: the > *users* of the kernel. Notably I'd really like to have kernel leads > from the main distros, ie Android, Fedora, Suse, Ubuntu. Agreed, for a maintainer summit to be useful, we need to have multiple sides present. Gathering core maintainers with key representatives of the downstream communities around the table is great, but I think we would be missing one category whose opinion is equally important: kernel developers. When everything goes well developers can be represented by their maintainers. That's the case where the process flows smoothly, so there isn't likely to be much to discuss. However, problems occurring in the maintenance process are likely to result in, if not conflicts, at least different views between maintainers and developers, in which case developers won't be represented at the summit. I'm not sure how to handle that. I certainly don't want to increase the number of attendees to include key representatives of developers (and while I'd be very curious to see how they would be selected, I doubt it would work in practice), but I also believe we need to address this class of maintainership issues. > I think that when we talk about process pain points, we definitely > need to have downstream involved. Greg is there with his stable > maintainer hat on too, but he's still "ours". > > It would be really good to have whoever is in charge of the Android > kernel there (not manager, but tech lead), and not make it a blame > game, but really try to also talk about how we could perhaps bridge > that gap somehow. > > I'm not sure who those people actually are, but I suspect this list > contains people who can point to each tech lead.. I think it's Laura > Abbott for Fedora, for example? > > > Do you plan it to be attached with some major conference, or as a > > stand-alone one? > > Oh, I was just assuming people were aware of the kernel summit <-> > maintainer summit thing. > > So this would be the maintainer side of the traditional kernel summit. > > This year it would be October in Prague, co-located with the European > ELC / LinuxCon / OpenSourceSummit thing. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:25 ` Laurent Pinchart @ 2017-04-19 19:40 ` Linus Torvalds 2017-04-19 19:45 ` Jens Axboe ` (3 more replies) 0 siblings, 4 replies; 135+ messages in thread From: Linus Torvalds @ 2017-04-19 19:40 UTC (permalink / raw) To: Laurent Pinchart Cc: ksummit, Greg Kroah-Hartman, David Miller, Dave Airlie, Doug Ledford, Ingo Molnar On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Agreed, for a maintainer summit to be useful, we need to have multiple sides > present. Gathering core maintainers with key representatives of the downstream > communities around the table is great, but I think we would be missing one > category whose opinion is equally important: kernel developers. > > When everything goes well developers can be represented by their maintainers. > That's the case where the process flows smoothly, so there isn't likely to be > much to discuss. However, problems occurring in the maintenance process are > likely to result in, if not conflicts, at least different views between > maintainers and developers, in which case developers won't be represented at > the summit. > > I'm not sure how to handle that. I certainly don't want to increase the number > of attendees to include key representatives of developers (and while I'd be > very curious to see how they would be selected, I doubt it would work in > practice), but I also believe we need to address this class of maintainership > issues. I do agree that it would be a great thing to have a "bitch at maintainers" session where developers get to vent frustration at how their patches are (or are _not_) accepted by maintainers. I know we've had issues in the VFS layer, with Al sometimes effectively dropping off the intenet for a time, for example. And I'm sure it happens elsewhere too, I'm just aware of the VFS side because it's one of the areas where I end up personally being a secondary maintainer. But the problem with that "bitch at maintainers" thing is that I can't for the life of me come up with a sane small set of people to do that. So I don't see it happening ;( Anyway, I have tried to gather "other groups" that aren't in that top-10 maintainers list, but are examples of people "around" the maintenance issues: - stable and linux-next: Ben Hutchings (stable) Stephen Rothwell (linux-next) - Infrastructure: Konstantin Ryabitsev (k.org) Fengguang Wu (kernel test robot) Steven Rostedt (ktest) Shuah Khan (tools/testing) Thorsten Leemhuis (regression tracking) Jonathan Corbet (documentation) - Security: Andy Lutomirski (security and core) Kees Cook (security) James Morris (security subsystem) - distro people: Laura Abbott (Fedora) Jiri Kosina (MM? JM?) (Suse) Rom Lemarchand (Android) - Hw vendor people? - Sponsor people? but I can't come up with a sane set of "leaf developers" or anything like that. We've just got too many. That's obviously a good problem to have, but it doesn't fit with the maintainer summit, because unless somebody can come up with some kind of prototypical spokesperson for that group (and to me, that doesn't seem likely), I don't see how to do it. (And I still suspect that we do want coverage of some remaining maintainership areas, ie filesystem and block layer, because the "top-10 maintainers" don't cover that at all. And I haven't heard suggestions for the networking side either, still assuming that Daem isn't interested since he never has been before..) Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:40 ` Linus Torvalds @ 2017-04-19 19:45 ` Jens Axboe 2017-04-19 19:50 ` Laurent Pinchart ` (2 subsequent siblings) 3 siblings, 0 replies; 135+ messages in thread From: Jens Axboe @ 2017-04-19 19:45 UTC (permalink / raw) To: Linus Torvalds, Laurent Pinchart Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On 04/19/2017 01:40 PM, Linus Torvalds wrote: > On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> >> Agreed, for a maintainer summit to be useful, we need to have multiple sides >> present. Gathering core maintainers with key representatives of the downstream >> communities around the table is great, but I think we would be missing one >> category whose opinion is equally important: kernel developers. >> >> When everything goes well developers can be represented by their maintainers. >> That's the case where the process flows smoothly, so there isn't likely to be >> much to discuss. However, problems occurring in the maintenance process are >> likely to result in, if not conflicts, at least different views between >> maintainers and developers, in which case developers won't be represented at >> the summit. >> >> I'm not sure how to handle that. I certainly don't want to increase the number >> of attendees to include key representatives of developers (and while I'd be >> very curious to see how they would be selected, I doubt it would work in >> practice), but I also believe we need to address this class of maintainership >> issues. > > I do agree that it would be a great thing to have a "bitch at > maintainers" session where developers get to vent frustration at how > their patches are (or are _not_) accepted by maintainers. > > I know we've had issues in the VFS layer, with Al sometimes > effectively dropping off the intenet for a time, for example. And I'm > sure it happens elsewhere too, I'm just aware of the VFS side because > it's one of the areas where I end up personally being a secondary > maintainer. > > But the problem with that "bitch at maintainers" thing is that I can't > for the life of me come up with a sane small set of people to do that. > So I don't see it happening ;( > > Anyway, I have tried to gather "other groups" that aren't in that > top-10 maintainers list, but are examples of people "around" the > maintenance issues: > > - stable and linux-next: > > Ben Hutchings (stable) > Stephen Rothwell (linux-next) > > - Infrastructure: > > Konstantin Ryabitsev (k.org) > Fengguang Wu (kernel test robot) > Steven Rostedt (ktest) > Shuah Khan (tools/testing) > Thorsten Leemhuis (regression tracking) > Jonathan Corbet (documentation) > > - Security: > > Andy Lutomirski (security and core) > Kees Cook (security) > James Morris (security subsystem) > > - distro people: > > Laura Abbott (Fedora) > Jiri Kosina (MM? JM?) (Suse) > Rom Lemarchand (Android) > > - Hw vendor people? > - Sponsor people? > > but I can't come up with a sane set of "leaf developers" or anything > like that. We've just got too many. That's obviously a good problem to > have, but it doesn't fit with the maintainer summit, because unless > somebody can come up with some kind of prototypical spokesperson for > that group (and to me, that doesn't seem likely), I don't see how to > do it. > > (And I still suspect that we do want coverage of some remaining > maintainership areas, ie filesystem and block layer, because the > "top-10 maintainers" don't cover that at all. And I haven't heard > suggestions for the networking side either, still assuming that Daem > isn't interested since he never has been before..) I haven't piped up yet, but the block layer was represented in your initial top-20 (or something like that) list. I can attend if you want representation on that side. I'll also mention that upstream kernel users aren't "just" distros. Facebook is a large consumer of upstream, and we feed everything we do back as well. I suspect we have at least as many users (or more) than some of the distros :-) -- Jens Axboe ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:40 ` Linus Torvalds 2017-04-19 19:45 ` Jens Axboe @ 2017-04-19 19:50 ` Laurent Pinchart 2017-04-19 19:55 ` James Bottomley 2017-04-19 20:14 ` Josh Triplett 2017-04-19 19:58 ` Konstantin Ryabitsev 2017-04-19 20:20 ` Jiri Kosina 3 siblings, 2 replies; 135+ messages in thread From: Laurent Pinchart @ 2017-04-19 19:50 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Greg Kroah-Hartman, David Miller, Dave Airlie, Doug Ledford, Ingo Molnar Hi Linus, On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote: > On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote: > > Agreed, for a maintainer summit to be useful, we need to have multiple > > sides present. Gathering core maintainers with key representatives of the > > downstream communities around the table is great, but I think we would be > > missing one category whose opinion is equally important: kernel > > developers. > > > > When everything goes well developers can be represented by their > > maintainers. That's the case where the process flows smoothly, so there > > isn't likely to be much to discuss. However, problems occurring in the > > maintenance process are likely to result in, if not conflicts, at least > > different views between maintainers and developers, in which case > > developers won't be represented at the summit. > > > > I'm not sure how to handle that. I certainly don't want to increase the > > number of attendees to include key representatives of developers (and > > while I'd be very curious to see how they would be selected, I doubt it > > would work in practice), but I also believe we need to address this class > > of maintainership issues. > > I do agree that it would be a great thing to have a "bitch at > maintainers" session where developers get to vent frustration at how > their patches are (or are _not_) accepted by maintainers. > > I know we've had issues in the VFS layer, with Al sometimes > effectively dropping off the intenet for a time, for example. And I'm > sure it happens elsewhere too, I'm just aware of the VFS side because > it's one of the areas where I end up personally being a secondary > maintainer. > > But the problem with that "bitch at maintainers" thing is that I can't > for the life of me come up with a sane small set of people to do that. > So I don't see it happening ;( I currently don't have any good idea to make that happen either, but I'll keep thinking about it :-) More than bitching at maintainers, I believe that lots of developers, especially "smaller" or infrequent kernel contributors, are frustrated by maintainership issues that the related maintainers might not even be aware of. One idea I've been thinking of was to gather constructive feedback (or just feedback that would then be filtered out of pointless finger-pointing and bitching) about our maintainers, aggregate it periodically, and submit it to the maintainers, possibly in an anonymized form. A maintainer summit is certainly no place to gather that feedback, but could be an occasion to decide whether such a process would be deemed useful. I for one, while I only maintain drivers and not whole subsystems, would certainly welcome constructive criticism in that area. > Anyway, I have tried to gather "other groups" that aren't in that > top-10 maintainers list, but are examples of people "around" the > maintenance issues: > > - stable and linux-next: > > Ben Hutchings (stable) > Stephen Rothwell (linux-next) > > - Infrastructure: > > Konstantin Ryabitsev (k.org) > Fengguang Wu (kernel test robot) > Steven Rostedt (ktest) > Shuah Khan (tools/testing) > Thorsten Leemhuis (regression tracking) > Jonathan Corbet (documentation) > > - Security: > > Andy Lutomirski (security and core) > Kees Cook (security) > James Morris (security subsystem) > > - distro people: > > Laura Abbott (Fedora) > Jiri Kosina (MM? JM?) (Suse) > Rom Lemarchand (Android) > > - Hw vendor people? > - Sponsor people? > > but I can't come up with a sane set of "leaf developers" or anything > like that. We've just got too many. That's obviously a good problem to > have, but it doesn't fit with the maintainer summit, because unless > somebody can come up with some kind of prototypical spokesperson for > that group (and to me, that doesn't seem likely), I don't see how to > do it. > > (And I still suspect that we do want coverage of some remaining > maintainership areas, ie filesystem and block layer, because the > "top-10 maintainers" don't cover that at all. And I haven't heard > suggestions for the networking side either, still assuming that Daem > isn't interested since he never has been before..) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:50 ` Laurent Pinchart @ 2017-04-19 19:55 ` James Bottomley 2017-04-20 8:26 ` Daniel Vetter 2017-04-25 16:02 ` Bart Van Assche 2017-04-19 20:14 ` Josh Triplett 1 sibling, 2 replies; 135+ messages in thread From: James Bottomley @ 2017-04-19 19:55 UTC (permalink / raw) To: Laurent Pinchart, Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Wed, 2017-04-19 at 22:50 +0300, Laurent Pinchart wrote: > Hi Linus, > > On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote: > > On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote: > > > Agreed, for a maintainer summit to be useful, we need to have > > > multiple sides present. Gathering core maintainers with key > > > representatives of the downstream communities around the table is > > > great, but I think we would be missing one category whose opinion > > > is equally important: kernel developers. > > > > > > When everything goes well developers can be represented by their > > > maintainers. That's the case where the process flows smoothly, so > > > there isn't likely to be much to discuss. However, problems > > > occurring in the maintenance process are likely to result in, if > > > not conflicts, at least different views between maintainers and > > > developers, in which case developers won't be represented at the > > > summit. > > > > > > I'm not sure how to handle that. I certainly don't want to > > > increase the number of attendees to include key representatives > > > of developers (and while I'd be very curious to see how they > > > would be selected, I doubt it would work in practice), but I also > > > believe we need to address this class of maintainership issues. > > > > I do agree that it would be a great thing to have a "bitch at > > maintainers" session where developers get to vent frustration at > > how their patches are (or are _not_) accepted by maintainers. > > > > I know we've had issues in the VFS layer, with Al sometimes > > effectively dropping off the intenet for a time, for example. And > > I'm sure it happens elsewhere too, I'm just aware of the VFS side > > because it's one of the areas where I end up personally being a > > secondary maintainer. > > > > But the problem with that "bitch at maintainers" thing is that I > > can't for the life of me come up with a sane small set of people to > > do that. So I don't see it happening ;( > > I currently don't have any good idea to make that happen either, but > I'll keep thinking about it :-) More than bitching at maintainers, I > believe that lots of developers, especially "smaller" or infrequent > kernel contributors, are frustrated by maintainership issues that the > related maintainers might not even be aware of. Isn't it easy? The Maintainers summit is going to be part of a larger kernel track within LinuxCon EU (not that everyone plans on staying on, of course, but several will be). Just put the bitch at Maintainers session in that as a round table, so any attendee of LinuxCon EU can come and complain if they want to. I think also it might be a good idea to separate internal process issues, which would be done in the small group from external ones, which should, perhaps, have the Kernel track at LinuxCon visibility. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:55 ` James Bottomley @ 2017-04-20 8:26 ` Daniel Vetter 2017-04-20 13:25 ` James Bottomley 2017-04-25 16:02 ` Bart Van Assche 1 sibling, 1 reply; 135+ messages in thread From: Daniel Vetter @ 2017-04-20 8:26 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, Apr 19, 2017 at 9:55 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > Isn't it easy? The Maintainers summit is going to be part of a larger > kernel track within LinuxCon EU (not that everyone plans on staying > on, of course, but several will be). Just put the bitch at Maintainers > session in that as a round table, so any attendee of LinuxCon EU can > come and complain if they want to. I don't think it's that easy. I guess due to the "interesting" stuff we're doing in drm I get to hear some of the frustration stories from leaf contributors. Picking a conference means you exclude folks who won't go there (and Linux is so huge that there's simply no single conference that would cover it all), but more important a common theme I'm hearing is that frustrated folks don't want to speak up in public, because if they piss of their maintainer, their problems just get worse. On the other hand they lack the power and influence to fix anything, so there's very little upside to speaking up about issues. The usual solution seems to eventually just quietly abandon upstream, or at least the particular subsystem. The other thing is that because Linuxcon has such a wide audience you might just get the peanut gallery kernel bashing from bystanders, not feedback from actual (or at least potential) contributors. Still worth trying I guess, but I wouldn't be surprised if there's not much coming out of such a feedback session. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 8:26 ` Daniel Vetter @ 2017-04-20 13:25 ` James Bottomley 0 siblings, 0 replies; 135+ messages in thread From: James Bottomley @ 2017-04-20 13:25 UTC (permalink / raw) To: Daniel Vetter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Thu, 2017-04-20 at 10:26 +0200, Daniel Vetter wrote: > On Wed, Apr 19, 2017 at 9:55 PM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > Isn't it easy? The Maintainers summit is going to be part of a > > larger kernel track within LinuxCon EU (not that everyone plans on > > staying on, of course, but several will be). Just put the bitch at > > Maintainers session in that as a round table, so any attendee of > > LinuxCon EU can come and complain if they want to. > > I don't think it's that easy. I guess due to the "interesting" stuff > we're doing in drm I get to hear some of the frustration stories from > leaf contributors. Picking a conference means you exclude folks who > won't go there (and Linux is so huge that there's simply no single > conference that would cover it all), Well, that's a reason for never doing anything at a conference, yes. However, the other way to look at it is that if the Maintainer summit rotates between US, EU and Asia and is allied to a tech conference in each, then we have a continent-local venue covering most of the world. So the argument isn't that this is a perfect solution, but that it's a good one because it gives people the opportunity to come and give feedback without having to have an invitation to the Maintainer summit. > but more important a common theme I'm hearing is that frustrated > folks don't want to speak up in public, because if they piss of their > maintainer, their problems just get worse. So perhaps they might turn up to give it privately. > On the other hand they lack the power and influence to fix > anything, so there's very little upside to speaking up about issues. > The usual solution seems to eventually just quietly abandon upstream, > or at least the particular subsystem. Empowerment is about giving people opportunities. I find most people take them. The fact that a few people may not avail themselves isn't a good reason for not trying. > The other thing is that because Linuxcon has such a wide audience you > might just get the peanut gallery kernel bashing from bystanders, not > feedback from actual (or at least potential) contributors. On that reasoning, we should abandon democracy immediately. James > Still worth trying I guess, but I wouldn't be surprised if there's > not much coming out of such a feedback session. > -Daniel ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:55 ` James Bottomley 2017-04-20 8:26 ` Daniel Vetter @ 2017-04-25 16:02 ` Bart Van Assche 2017-04-25 16:38 ` Guenter Roeck ` (2 more replies) 1 sibling, 3 replies; 135+ messages in thread From: Bart Van Assche @ 2017-04-25 16:02 UTC (permalink / raw) To: James Bottomley, Laurent Pinchart, Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On 04/19/17 12:55, James Bottomley wrote: > On Wed, 2017-04-19 at 22:50 +0300, Laurent Pinchart wrote: >> On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote: >>> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote: >>>> Agreed, for a maintainer summit to be useful, we need to have >>>> multiple sides present. Gathering core maintainers with key >>>> representatives of the downstream communities around the table is >>>> great, but I think we would be missing one category whose opinion >>>> is equally important: kernel developers. >>>> >>>> When everything goes well developers can be represented by their >>>> maintainers. That's the case where the process flows smoothly, so >>>> there isn't likely to be much to discuss. However, problems >>>> occurring in the maintenance process are likely to result in, if >>>> not conflicts, at least different views between maintainers and >>>> developers, in which case developers won't be represented at the >>>> summit. >>>> >>>> I'm not sure how to handle that. I certainly don't want to >>>> increase the number of attendees to include key representatives >>>> of developers (and while I'd be very curious to see how they >>>> would be selected, I doubt it would work in practice), but I also >>>> believe we need to address this class of maintainership issues. >>> >>> I do agree that it would be a great thing to have a "bitch at >>> maintainers" session where developers get to vent frustration at >>> how their patches are (or are _not_) accepted by maintainers. >>> >>> I know we've had issues in the VFS layer, with Al sometimes >>> effectively dropping off the intenet for a time, for example. And >>> I'm sure it happens elsewhere too, I'm just aware of the VFS side >>> because it's one of the areas where I end up personally being a >>> secondary maintainer. >>> >>> But the problem with that "bitch at maintainers" thing is that I >>> can't for the life of me come up with a sane small set of people to >>> do that. So I don't see it happening ;( >> >> I currently don't have any good idea to make that happen either, but >> I'll keep thinking about it :-) More than bitching at maintainers, I >> believe that lots of developers, especially "smaller" or infrequent >> kernel contributors, are frustrated by maintainership issues that the >> related maintainers might not even be aware of. > > Isn't it easy? The Maintainers summit is going to be part of a larger > kernel track within LinuxCon EU (not that everyone plans on staying > on, of course, but several will be). Just put the bitch at Maintainers > session in that as a round table, so any attendee of LinuxCon EU can > come and complain if they want to. We all know that the stability and the long-term success of the Linux kernel strongly depend on how well kernel maintainers do their job. What I noticed myself is that for some subsystems I contribute to (e.g. block, SCSI and RDMA) maintainers provide feedback about patches within a very reasonable time. For two other subsystems I contribute to it can take weeks or months before adequate feedback is provided. Sorry but I don't think that it is acceptable that it takes that long before feedback is provided and hence that this is a topic that deserves to be discussed during the maintainer summit. Bart. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-25 16:02 ` Bart Van Assche @ 2017-04-25 16:38 ` Guenter Roeck 2017-04-25 16:56 ` Mark Brown 2017-04-26 8:42 ` Dan Carpenter 2 siblings, 0 replies; 135+ messages in thread From: Guenter Roeck @ 2017-04-25 16:38 UTC (permalink / raw) To: Bart Van Assche Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote: > On 04/19/17 12:55, James Bottomley wrote: > > On Wed, 2017-04-19 at 22:50 +0300, Laurent Pinchart wrote: > >> On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote: > >>> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote: > >>>> Agreed, for a maintainer summit to be useful, we need to have > >>>> multiple sides present. Gathering core maintainers with key > >>>> representatives of the downstream communities around the table is > >>>> great, but I think we would be missing one category whose opinion > >>>> is equally important: kernel developers. > >>>> > >>>> When everything goes well developers can be represented by their > >>>> maintainers. That's the case where the process flows smoothly, so > >>>> there isn't likely to be much to discuss. However, problems > >>>> occurring in the maintenance process are likely to result in, if > >>>> not conflicts, at least different views between maintainers and > >>>> developers, in which case developers won't be represented at the > >>>> summit. > >>>> > >>>> I'm not sure how to handle that. I certainly don't want to > >>>> increase the number of attendees to include key representatives > >>>> of developers (and while I'd be very curious to see how they > >>>> would be selected, I doubt it would work in practice), but I also > >>>> believe we need to address this class of maintainership issues. > >>> > >>> I do agree that it would be a great thing to have a "bitch at > >>> maintainers" session where developers get to vent frustration at > >>> how their patches are (or are _not_) accepted by maintainers. > >>> > >>> I know we've had issues in the VFS layer, with Al sometimes > >>> effectively dropping off the intenet for a time, for example. And > >>> I'm sure it happens elsewhere too, I'm just aware of the VFS side > >>> because it's one of the areas where I end up personally being a > >>> secondary maintainer. > >>> > >>> But the problem with that "bitch at maintainers" thing is that I > >>> can't for the life of me come up with a sane small set of people to > >>> do that. So I don't see it happening ;( > >> > >> I currently don't have any good idea to make that happen either, but > >> I'll keep thinking about it :-) More than bitching at maintainers, I > >> believe that lots of developers, especially "smaller" or infrequent > >> kernel contributors, are frustrated by maintainership issues that the > >> related maintainers might not even be aware of. > > > > Isn't it easy? The Maintainers summit is going to be part of a larger > > kernel track within LinuxCon EU (not that everyone plans on staying > > on, of course, but several will be). Just put the bitch at Maintainers > > session in that as a round table, so any attendee of LinuxCon EU can > > come and complain if they want to. > > We all know that the stability and the long-term success of the Linux > kernel strongly depend on how well kernel maintainers do their job. What > I noticed myself is that for some subsystems I contribute to (e.g. > block, SCSI and RDMA) maintainers provide feedback about patches within > a very reasonable time. For two other subsystems I contribute to it can > take weeks or months before adequate feedback is provided. Sorry but I > don't think that it is acceptable that it takes that long before > feedback is provided and hence that this is a topic that deserves to be > discussed during the maintainer summit. > Double edged sword. You are right when it comes to a subsystem with active participants who are willing to review patches. On the other side, for a subsystem which has been declared "obscure" and/or "obsolete" in public, it may well be that the maintainer is the only person in the world looking at patches. I would argue that you should give the maintainers of such subsystems a little slack (or maybe even volunteer to review some patches ?). Thanks, Guenter ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-25 16:02 ` Bart Van Assche 2017-04-25 16:38 ` Guenter Roeck @ 2017-04-25 16:56 ` Mark Brown 2017-04-26 3:47 ` Bart Van Assche 2017-04-26 8:42 ` Dan Carpenter 2 siblings, 1 reply; 135+ messages in thread From: Mark Brown @ 2017-04-25 16:56 UTC (permalink / raw) To: Bart Van Assche Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller [-- Attachment #1: Type: text/plain, Size: 1348 bytes --] On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote: > I noticed myself is that for some subsystems I contribute to (e.g. > block, SCSI and RDMA) maintainers provide feedback about patches within > a very reasonable time. For two other subsystems I contribute to it can > take weeks or months before adequate feedback is provided. Sorry but I > don't think that it is acceptable that it takes that long before > feedback is provided and hence that this is a topic that deserves to be > discussed during the maintainer summit. This comes up most years... is a discussion likely to come up with anything new that's concretely actionable? That said a related thing that feels like it's definitely a maintainer summit thing is getting new things into the kernel that somehow sit between maintainers (new subsystems being the most obvious example) - we do have a gap where people will negatively review things but won't either take them or positively review them which can go on for very long periods with people being just ignored (or worse just getting new people popping up every once in a while with negative comments). That's obviously offputting for submitters, and can be especially bad if it's coupled with other stuff like people taking on board the derogatory comments that often get made about some segments of the industry. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-25 16:56 ` Mark Brown @ 2017-04-26 3:47 ` Bart Van Assche 2017-04-26 8:39 ` Geert Uytterhoeven 2017-04-26 14:21 ` Mark Brown 0 siblings, 2 replies; 135+ messages in thread From: Bart Van Assche @ 2017-04-26 3:47 UTC (permalink / raw) To: Mark Brown Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, James Bottomley, Doug Ledford, Ingo Molnar On 04/25/17 09:56, Mark Brown wrote: > On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote: >> I noticed myself is that for some subsystems I contribute to (e.g. >> block, SCSI and RDMA) maintainers provide feedback about patches within >> a very reasonable time. For two other subsystems I contribute to it can >> take weeks or months before adequate feedback is provided. Sorry but I >> don't think that it is acceptable that it takes that long before >> feedback is provided and hence that this is a topic that deserves to be >> discussed during the maintainer summit. > > This comes up most years... is a discussion likely to come up with > anything new that's concretely actionable? Hello Mark, If priorities change over time and someone who had initially sufficient time to be a kernel maintainer and later on that changes that's something I can understand. But what I do not understand is if someone no longer has enough time to be a kernel maintainer why he or she does not look for help and e.g. asks someone who has the required skills and who is interested in this kind of work to become a co-maintainer? Bart. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 3:47 ` Bart Van Assche @ 2017-04-26 8:39 ` Geert Uytterhoeven 2017-04-26 14:21 ` Mark Brown 1 sibling, 0 replies; 135+ messages in thread From: Geert Uytterhoeven @ 2017-04-26 8:39 UTC (permalink / raw) To: Bart Van Assche Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller On Wed, Apr 26, 2017 at 5:47 AM, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote: > On 04/25/17 09:56, Mark Brown wrote: >> On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote: >>> I noticed myself is that for some subsystems I contribute to (e.g. >>> block, SCSI and RDMA) maintainers provide feedback about patches within >>> a very reasonable time. For two other subsystems I contribute to it can >>> take weeks or months before adequate feedback is provided. Sorry but I >>> don't think that it is acceptable that it takes that long before >>> feedback is provided and hence that this is a topic that deserves to be >>> discussed during the maintainer summit. >> >> This comes up most years... is a discussion likely to come up with >> anything new that's concretely actionable? > > Hello Mark, > > If priorities change over time and someone who had initially sufficient > time to be a kernel maintainer and later on that changes that's > something I can understand. But what I do not understand is if someone > no longer has enough time to be a kernel maintainer why he or she does > not look for help and e.g. asks someone who has the required skills and > who is interested in this kind of work to become a co-maintainer? He/she may not have enough time for/other priorities than looking for a skilled replacement? 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] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 3:47 ` Bart Van Assche 2017-04-26 8:39 ` Geert Uytterhoeven @ 2017-04-26 14:21 ` Mark Brown 2017-04-26 14:51 ` David Miller 1 sibling, 1 reply; 135+ messages in thread From: Mark Brown @ 2017-04-26 14:21 UTC (permalink / raw) To: Bart Van Assche Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, James Bottomley, Doug Ledford, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 1068 bytes --] On Wed, Apr 26, 2017 at 03:47:13AM +0000, Bart Van Assche wrote: > On 04/25/17 09:56, Mark Brown wrote: > > This comes up most years... is a discussion likely to come up with > > anything new that's concretely actionable? > If priorities change over time and someone who had initially sufficient > time to be a kernel maintainer and later on that changes that's > something I can understand. But what I do not understand is if someone > no longer has enough time to be a kernel maintainer why he or she does > not look for help and e.g. asks someone who has the required skills and > who is interested in this kind of work to become a co-maintainer? You'd have to ask the relevant people... based on the times I've looked at problematic subsystems it often seems that either people have completely vanished for whatever reason or there's very little other interest in the subsystem so no obvious candidates. I'm not saying that there isn't a problem, I'm just saying that it's not new and it doesn't seem like the situation changed much. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 14:21 ` Mark Brown @ 2017-04-26 14:51 ` David Miller 2017-04-26 15:15 ` Mark Brown 0 siblings, 1 reply; 135+ messages in thread From: David Miller @ 2017-04-26 14:51 UTC (permalink / raw) To: broonie Cc: ksummit-discuss, airlied, gregkh, James.Bottomley, dledford, Bart.VanAssche, mingo From: Mark Brown <broonie@kernel.org> Date: Wed, 26 Apr 2017 15:21:49 +0100 > On Wed, Apr 26, 2017 at 03:47:13AM +0000, Bart Van Assche wrote: >> On 04/25/17 09:56, Mark Brown wrote: > >> > This comes up most years... is a discussion likely to come up with >> > anything new that's concretely actionable? > >> If priorities change over time and someone who had initially sufficient >> time to be a kernel maintainer and later on that changes that's >> something I can understand. But what I do not understand is if someone >> no longer has enough time to be a kernel maintainer why he or she does >> not look for help and e.g. asks someone who has the required skills and >> who is interested in this kind of work to become a co-maintainer? > > You'd have to ask the relevant people... based on the times I've looked > at problematic subsystems it often seems that either people have > completely vanished for whatever reason or there's very little other > interest in the subsystem so no obvious candidates. I'm not saying that > there isn't a problem, I'm just saying that it's not new and it doesn't > seem like the situation changed much. Often people just don't want to let go and give up "control" of something they've watched over for a long period of time. I think we suffer from this a lot. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 14:51 ` David Miller @ 2017-04-26 15:15 ` Mark Brown 0 siblings, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-26 15:15 UTC (permalink / raw) To: David Miller Cc: ksummit-discuss, airlied, gregkh, James.Bottomley, dledford, Bart.VanAssche, mingo [-- Attachment #1: Type: text/plain, Size: 952 bytes --] On Wed, Apr 26, 2017 at 10:51:23AM -0400, David Miller wrote: > > You'd have to ask the relevant people... based on the times I've looked > > at problematic subsystems it often seems that either people have > > completely vanished for whatever reason or there's very little other > > interest in the subsystem so no obvious candidates. I'm not saying that > > there isn't a problem, I'm just saying that it's not new and it doesn't > > seem like the situation changed much. > Often people just don't want to let go and give up "control" of > something they've watched over for a long period of time. > I think we suffer from this a lot. Yeah, that's definitely a part of it too - it often goes hand in hand with the lack of other reviewers thing as the two can easily feed off each other, it's a lot easier to let go if there's someone to hand things over to but if things aren't working well that can be discouraging to potential new reviewers. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-25 16:02 ` Bart Van Assche 2017-04-25 16:38 ` Guenter Roeck 2017-04-25 16:56 ` Mark Brown @ 2017-04-26 8:42 ` Dan Carpenter 2017-04-26 13:58 ` Martin K. Petersen 2017-04-26 15:02 ` Bart Van Assche 2 siblings, 2 replies; 135+ messages in thread From: Dan Carpenter @ 2017-04-26 8:42 UTC (permalink / raw) To: Bart Van Assche Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller On Tue, Apr 25, 2017 at 09:02:12AM -0700, Bart Van Assche wrote: > We all know that the stability and the long-term success of the Linux > kernel strongly depend on how well kernel maintainers do their job. What > I noticed myself is that for some subsystems I contribute to (e.g. > block, SCSI and RDMA) maintainers provide feedback about patches within > a very reasonable time. For two other subsystems I contribute to it can > take weeks or months before adequate feedback is provided. Sorry but I > don't think that it is acceptable that it takes that long before > feedback is provided and hence that this is a topic that deserves to be > discussed during the maintainer summit. > It's Ok to wait weeks. Months is not OK. If maintainers are not reading their email then you can try forwarding the patches through Andrew. I feel like I haven't had such a huge problem with this recently... Are we talking about other arches besides x86 and ARM? My patches are normally simple is probably part of the difference. regards, dan carpenter ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 8:42 ` Dan Carpenter @ 2017-04-26 13:58 ` Martin K. Petersen 2017-04-26 14:15 ` Andrew Lunn 2017-04-26 14:31 ` James Bottomley 2017-04-26 15:02 ` Bart Van Assche 1 sibling, 2 replies; 135+ messages in thread From: Martin K. Petersen @ 2017-04-26 13:58 UTC (permalink / raw) To: Dan Carpenter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, James Bottomley, Doug Ledford, Bart Van Assche, Ingo Molnar Dan, > My patches are normally simple is probably part of the difference. Patch complexity usually has something to do with it. In SCSI I deal with simple patches right away. Other people are also willing to jump in and review because the time commitment to do so is low. It's much harder to get people to review intricate core changes because they need a significant chunk of uninterrupted time. And that's a precious resource. Another gripe of mine wrt. big vs. small is that almost all vendor driver updates come in the form of "30+ patches to update the driver to version XYZ". Often a week before the merge window. And then they wonder why nobody reviews them. Well, duh. That's a huge chunk of time for somebody to commit. It would be much better if they'd drop the arbitrary and pointless "driver version XYZ" notion and just send a few patches per week. Reviewers are much more inclined to go "Oh, I have 15 minutes now, let me check my inbox". In most cases the reviews would also be more thorough because you don't lose focus after patch number 7 and just want this entire thing to be over before your brain turns into mush. Anyway. Just being the devil's advocate here. It just seems there's a consistent "maintainers are bad/lazy/unresponsive" theme going on. But for better or for worse, patch submitters are often presenting their work in ways that are completely indigestible. Not just to the maintainers, but to the people willing to do reviews. Not sure what we can do to address this? I often have big patch series sitting tagged in my inbox for days/weeks while I chip away at them. But the reality is that few, if any, reviewers do the same. If there is not enough time to review a submission first time people see it in their inbox, chances are that the review opportunity is lost forever. And if nobody else reviews the patches the burden falls on me, making my backlog even bigger. -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 13:58 ` Martin K. Petersen @ 2017-04-26 14:15 ` Andrew Lunn 2017-04-26 15:42 ` Martin K. Petersen 2017-04-26 14:31 ` James Bottomley 1 sibling, 1 reply; 135+ messages in thread From: Andrew Lunn @ 2017-04-26 14:15 UTC (permalink / raw) To: Martin K. Petersen Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, Bart Van Assche, David Miller, Dan Carpenter > Another gripe of mine wrt. big vs. small is that almost all vendor > driver updates come in the form of "30+ patches to update the driver to > version XYZ". Often a week before the merge window. And then they wonder > why nobody reviews them. Well, duh. That's a huge chunk of time for > somebody to commit. > Anyway. Just being the devil's advocate here. It just seems there's a > consistent "maintainers are bad/lazy/unresponsive" theme going on. But > for better or for worse, patch submitters are often presenting their > work in ways that are completely indigestible. What works well with netdev is that the maintainers simply NACK the patches within a day and ask them to be submitted in smaller batches. In my opinion, part of being a Maintainer is educating patch submitters how the process should work and how best to present their work so that it can be reviewed. It takes a bit of effort, but the returns are worth it. Andrew ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 14:15 ` Andrew Lunn @ 2017-04-26 15:42 ` Martin K. Petersen 0 siblings, 0 replies; 135+ messages in thread From: Martin K. Petersen @ 2017-04-26 15:42 UTC (permalink / raw) To: Andrew Lunn Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, Bart Van Assche, David Miller, Dan Carpenter Andrew, > What works well with netdev is that the maintainers simply NACK the > patches within a day and ask them to be submitted in smaller batches. > > In my opinion, part of being a Maintainer is educating patch > submitters how the process should work and how best to present their > work so that it can be reviewed. It takes a bit of effort, but the > returns are worth it. It's not for lack of trying. But the response typically that "our internal process/version number/qual cycle/release schedule is more important than getting the patches upstream". I think that's probably more of an issue in SCSI than in other subsystems due to enterprise manufacturer inertia... -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 13:58 ` Martin K. Petersen 2017-04-26 14:15 ` Andrew Lunn @ 2017-04-26 14:31 ` James Bottomley 2017-04-26 14:34 ` Jiri Kosina 1 sibling, 1 reply; 135+ messages in thread From: James Bottomley @ 2017-04-26 14:31 UTC (permalink / raw) To: Martin K. Petersen, Dan Carpenter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, Bart Van Assche, David Miller On Wed, 2017-04-26 at 09:58 -0400, Martin K. Petersen wrote: > Anyway. Just being the devil's advocate here. It just seems there's a > consistent "maintainers are bad/lazy/unresponsive" theme going on. > But for better or for worse, patch submitters are often presenting > their work in ways that are completely indigestible. Not just to the > maintainers, but to the people willing to do reviews. I definitely agree with this. Complain about the maintainer because my patch hasn't gone in is fairly common pattern. > Not sure what we can do to address this? I often have big patch > series sitting tagged in my inbox for days/weeks while I chip away at > them. But the reality is that few, if any, reviewers do the same. If > there is not enough time to review a submission first time people see > it in their inbox, chances are that the review opportunity is lost > forever. One thing we tried a while ago, which perhaps we should discuss resurrecting is the idea of holding up patches until the submitter has enough current reviews. At base this means for two driver patches, each submitter reviews the other patches. When we tried this in SCSI we had mixed results. The problem is that holding up patches in this way causes even more complaints, so you have to be really disciplined about it (and up front about the reasons). However, I still think finding ways of encouraging submitters (who obviously should understand the code) to participate equally in the review process seems to be the scalable way forwards ... the problem is how to do it without causing huge ructions. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 14:31 ` James Bottomley @ 2017-04-26 14:34 ` Jiri Kosina 2017-04-26 14:43 ` James Bottomley 0 siblings, 1 reply; 135+ messages in thread From: Jiri Kosina @ 2017-04-26 14:34 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Bart Van Assche, Ingo Molnar, Dan Carpenter On Wed, 26 Apr 2017, James Bottomley wrote: > When we tried this in SCSI we had mixed results. The problem is that > holding up patches in this way causes even more complaints, so you have > to be really disciplined about it (and up front about the reasons). Another problem is that sending e-mail containing 'Reviewed-by:' is way too easy if it's being motivated by something else than a real desire to actually perform the review. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 14:34 ` Jiri Kosina @ 2017-04-26 14:43 ` James Bottomley 2017-04-27 9:06 ` Jani Nikula 0 siblings, 1 reply; 135+ messages in thread From: James Bottomley @ 2017-04-26 14:43 UTC (permalink / raw) To: Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, Bart Van Assche, David Miller, Dan Carpenter On Wed, 2017-04-26 at 16:34 +0200, Jiri Kosina wrote: > On Wed, 26 Apr 2017, James Bottomley wrote: > > > When we tried this in SCSI we had mixed results. The problem is > > that holding up patches in this way causes even more complaints, so > > you have to be really disciplined about it (and up front about the > > reasons). > > Another problem is that sending e-mail containing 'Reviewed-by:' is > way too easy if it's being motivated by something else than a real > desire to actually perform the review. Agreed, but I think you'll find most maintainers have a "trust factor" for reviewers. Perhaps we should discuss how we arrive at this and how we should make it more public. The way I often deal with less trusted reviewers is to redo their review and point out all the things they missed and ask them not to come back until they can be more thorough. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 14:43 ` James Bottomley @ 2017-04-27 9:06 ` Jani Nikula 2017-04-27 10:41 ` Lee Jones 2017-04-27 15:40 ` Wolfram Sang 0 siblings, 2 replies; 135+ messages in thread From: Jani Nikula @ 2017-04-27 9:06 UTC (permalink / raw) To: James Bottomley, Jiri Kosina Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Bart Van Assche, Ingo Molnar, Dan Carpenter On Wed, 26 Apr 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > Agreed, but I think you'll find most maintainers have a "trust factor" > for reviewers. Perhaps we should discuss how we arrive at this and how > we should make it more public. The way I often deal with less trusted > reviewers is to redo their review and point out all the things they > missed and ask them not to come back until they can be more thorough. I think that's also a bit harsh, because I think the only way to become a better reviewer is to... review. I know it's hard to balance being welcoming to new reviewers and ensuring the patches do get proper review in the end. Certainly one thing that increases my trust in a review is the amount of review comments on the patch, even if there's a Reviewed-by at the end. Basically any hints that the reviewer has actually thought about the changes. On a related note, as maintainers I think we need to put more attention to recording the review credits in the commits. It's not unusual for review to be more work than writing the patch. The patch authors may be new contributors, or just looking at their specific use case, but the reviewer should look at the big picture. I think Jon will start tracking reviews more regularly, like he did for v4.11 stats [1], but obviously the stats are only as good as the input. BR, Jani. [1] https://lwn.net/Articles/720336/ -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-27 9:06 ` Jani Nikula @ 2017-04-27 10:41 ` Lee Jones 2017-04-27 11:02 ` Hannes Reinecke 2017-04-27 15:40 ` Wolfram Sang 1 sibling, 1 reply; 135+ messages in thread From: Lee Jones @ 2017-04-27 10:41 UTC (permalink / raw) To: Jani Nikula Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, Bart Van Assche, David Miller, Dan Carpenter On Thu, 27 Apr 2017, Jani Nikula wrote: > On Wed, 26 Apr 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > Agreed, but I think you'll find most maintainers have a "trust factor" > > for reviewers. Perhaps we should discuss how we arrive at this and how > > we should make it more public. The way I often deal with less trusted > > reviewers is to redo their review and point out all the things they > > missed and ask them not to come back until they can be more thorough. > > I think that's also a bit harsh, because I think the only way to become > a better reviewer is to... review. I know it's hard to balance being > welcoming to new reviewers and ensuring the patches do get proper review > in the end. I'm inclined to agree, this is a harsh approach. My personal method is to allow anyone to review, regardless of their credibility/trust status. I make a point not to hamper or criticise anyone that's genuinely tying to help, unless of f course they are dishing out bogus review comments, then those will need addressing, but only picking up even say 10% of the issues really isn't a problem. It doesn't matter how many points are picked-up or missed, we as Maintainers can always conduct an additional review or one in parallel. I find additional reviewers particularly helpful if I'm overloaded, since I can then insist that the contributor fixes all outstanding review comments before I conduct my, hopefully thorough, review. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blogs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-27 10:41 ` Lee Jones @ 2017-04-27 11:02 ` Hannes Reinecke 2017-04-27 14:17 ` James Bottomley 0 siblings, 1 reply; 135+ messages in thread From: Hannes Reinecke @ 2017-04-27 11:02 UTC (permalink / raw) To: ksummit-discuss On 04/27/2017 12:41 PM, Lee Jones wrote: > On Thu, 27 Apr 2017, Jani Nikula wrote: >> On Wed, 26 Apr 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: >>> Agreed, but I think you'll find most maintainers have a "trust factor" >>> for reviewers. Perhaps we should discuss how we arrive at this and how >>> we should make it more public. The way I often deal with less trusted >>> reviewers is to redo their review and point out all the things they >>> missed and ask them not to come back until they can be more thorough. >> >> I think that's also a bit harsh, because I think the only way to become >> a better reviewer is to... review. I know it's hard to balance being >> welcoming to new reviewers and ensuring the patches do get proper review >> in the end. > > I'm inclined to agree, this is a harsh approach. My personal method > is to allow anyone to review, regardless of their credibility/trust > status. I make a point not to hamper or criticise anyone that's > genuinely tying to help, unless of f course they are dishing out bogus > review comments, then those will need addressing, but only picking up > even say 10% of the issues really isn't a problem. It doesn't matter > how many points are picked-up or missed, we as Maintainers can always > conduct an additional review or one in parallel. > > I find additional reviewers particularly helpful if I'm overloaded, > since I can then insist that the contributor fixes all outstanding > review comments before I conduct my, hopefully thorough, review. > Indeed. From my POV the biggest problem is a shortage of reviewers, and we should be working on getting that resolved. In fact, most developers I'm working with simply are too scared to do any reviews, feeling as they do not being qualified enough. If we take the abovementioned route that's a sure way of putting them off reviewing for good. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.com +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-27 11:02 ` Hannes Reinecke @ 2017-04-27 14:17 ` James Bottomley 2017-04-28 0:24 ` Rafael J. Wysocki 0 siblings, 1 reply; 135+ messages in thread From: James Bottomley @ 2017-04-27 14:17 UTC (permalink / raw) To: Hannes Reinecke, ksummit-discuss On Thu, 2017-04-27 at 13:02 +0200, Hannes Reinecke wrote: > On 04/27/2017 12:41 PM, Lee Jones wrote: > > On Thu, 27 Apr 2017, Jani Nikula wrote: > > > On Wed, 26 Apr 2017, James Bottomley < > > > James.Bottomley@HansenPartnership.com> wrote: > > > > Agreed, but I think you'll find most maintainers have a "trust > > > > factor" for reviewers. Perhaps we should discuss how we arrive > > > > at this and how we should make it more public. The way I often > > > > deal with less trusted reviewers is to redo their review and > > > > point out all the things they missed and ask them not to come > > > > back until they can be more thorough. > > > > > > I think that's also a bit harsh, because I think the only way to > > > become a better reviewer is to... review. I know it's hard to > > > balance being welcoming to new reviewers and ensuring the patches > > > do get proper review in the end. > > > > I'm inclined to agree, this is a harsh approach. My personal > > method is to allow anyone to review, regardless of their > > credibility/trust status. I make a point not to hamper or > > criticise anyone that's genuinely tying to help, unless of f course > > they are dishing out bogus review comments, then those will need > > addressing, but only picking up even say 10% of the issues really > > isn't a problem. It doesn't matter how many points are picked-up > > or missed, we as Maintainers can always conduct an additional > > review or one in parallel. OK, so I should clarify that where I'm coming from is that I want not to have to review something if someone else has already done so. I suppose I should add that you mostly get these type of comments from me if I expected I could rely on your review but a random inspection found significant issues. > > I find additional reviewers particularly helpful if I'm overloaded, > > since I can then insist that the contributor fixes all outstanding > > review comments before I conduct my, hopefully thorough, review. > > > Indeed. From my POV the biggest problem is a shortage of reviewers, > and we should be working on getting that resolved. So wouldn't making review a precondition for patch acceptance be a strategy for at least helping with this? > In fact, most developers I'm working with simply are too scared to do > any reviews, feeling as they do not being qualified enough. > If we take the abovementioned route that's a sure way of putting them > off reviewing for good. I actually don't really believe people are afraid to review code. I think mostly (particularly in SCSI) they've got their hands full with constructing submissions and don't want to expend the additional bandwidth. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-27 14:17 ` James Bottomley @ 2017-04-28 0:24 ` Rafael J. Wysocki 0 siblings, 0 replies; 135+ messages in thread From: Rafael J. Wysocki @ 2017-04-28 0:24 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss On Thursday, April 27, 2017 10:17:58 AM James Bottomley wrote: > On Thu, 2017-04-27 at 13:02 +0200, Hannes Reinecke wrote: > > On 04/27/2017 12:41 PM, Lee Jones wrote: > > > On Thu, 27 Apr 2017, Jani Nikula wrote: > > > > On Wed, 26 Apr 2017, James Bottomley < > > > > James.Bottomley@HansenPartnership.com> wrote: > > > > > Agreed, but I think you'll find most maintainers have a "trust > > > > > factor" for reviewers. Perhaps we should discuss how we arrive > > > > > at this and how we should make it more public. The way I often > > > > > deal with less trusted reviewers is to redo their review and > > > > > point out all the things they missed and ask them not to come > > > > > back until they can be more thorough. > > > > > > > > I think that's also a bit harsh, because I think the only way to > > > > become a better reviewer is to... review. I know it's hard to > > > > balance being welcoming to new reviewers and ensuring the patches > > > > do get proper review in the end. > > > > > > I'm inclined to agree, this is a harsh approach. My personal > > > method is to allow anyone to review, regardless of their > > > credibility/trust status. I make a point not to hamper or > > > criticise anyone that's genuinely tying to help, unless of f course > > > they are dishing out bogus review comments, then those will need > > > addressing, but only picking up even say 10% of the issues really > > > isn't a problem. It doesn't matter how many points are picked-up > > > or missed, we as Maintainers can always conduct an additional > > > review or one in parallel. > > OK, so I should clarify that where I'm coming from is that I want not > to have to review something if someone else has already done so. I > suppose I should add that you mostly get these type of comments from me > if I expected I could rely on your review but a random inspection found > significant issues. Right, but this is not a black-and-white situation IMO. Reviewers may overlook things even though they do their best and I guess that happens to everyone occasionally. One way to look at code review is as advice in a decision making process. Of course, you are more likely to listen to people who tend to give you good advice, but then they may not be right this time around and the decision is for you to make anyway. > > > I find additional reviewers particularly helpful if I'm overloaded, > > > since I can then insist that the contributor fixes all outstanding > > > review comments before I conduct my, hopefully thorough, review. > > > > > Indeed. From my POV the biggest problem is a shortage of reviewers, > > and we should be working on getting that resolved. > > So wouldn't making review a precondition for patch acceptance be a > strategy for at least helping with this? I would be very careful about setting rules like that unless you absoultely believe that you'll never need to break them, whatever the reason. OTOH if people realize that doing review generally helps their patches to be accepted, that may actually work. :-) > > In fact, most developers I'm working with simply are too scared to do > > any reviews, feeling as they do not being qualified enough. > > If we take the abovementioned route that's a sure way of putting them > > off reviewing for good. > > I actually don't really believe people are afraid to review code. I > think mostly (particularly in SCSI) they've got their hands full with > constructing submissions and don't want to expend the additional > bandwidth. Right. There needs to be a clear benefit for the reviewer and ideally such that can be presented to their management as a good deal. Today, the perceived value of code changes going in is much higher and people allocate their time accordingly. Thanks, Rafael ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-27 9:06 ` Jani Nikula 2017-04-27 10:41 ` Lee Jones @ 2017-04-27 15:40 ` Wolfram Sang 1 sibling, 0 replies; 135+ messages in thread From: Wolfram Sang @ 2017-04-27 15:40 UTC (permalink / raw) To: Jani Nikula Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, Bart Van Assche, David Miller, Dan Carpenter [-- Attachment #1: Type: text/plain, Size: 1664 bytes --] > On a related note, as maintainers I think we need to put more attention > to recording the review credits in the commits. It's not unusual for > review to be more work than writing the patch. The patch authors may be > new contributors, or just looking at their specific use case, but the > reviewer should look at the big picture. I think Jon will start tracking > reviews more regularly, like he did for v4.11 stats [1], but obviously > the stats are only as good as the input. I fully agree to this. I hacked git-request-pull to include a list of people who reviewed or tested patches. The patch is quite a hack, though. As it works for me(tm) nonetheless, I finally set up a repo where I will put such snippets which help me in maintaining my subsystem. And I started the latest version of said patch a minute ago. So, if other people are interested, it should be more accessible now: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/snippets.git To get you an idea, here is some example output. More details can be found in the patch description itself: === standard pull-request The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: ... Vlad Tsyrklevich (1): i2c: fix kernel memory disclosure in dev interface === new stuff starts here with much appreciated quality assurance from ---------------------------------------------------------------- Andy Shevchenko (1): (Rev.) i2c: piix4: Avoid race conditions with IMC Benjamin Tissoires (1): (Test) i2c: do not enable fall back to Host Notify by default Vladimir Zapolskiy (1): (Rev.) i2c: print correct device invalid address === diffstat, ... [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 8:42 ` Dan Carpenter 2017-04-26 13:58 ` Martin K. Petersen @ 2017-04-26 15:02 ` Bart Van Assche 2017-04-26 15:25 ` James Bottomley 1 sibling, 1 reply; 135+ messages in thread From: Bart Van Assche @ 2017-04-26 15:02 UTC (permalink / raw) To: dan.carpenter Cc: ksummit-discuss, airlied, gregkh, davem, James.Bottomley, dledford, mingo On Wed, 2017-04-26 at 11:42 +0300, Dan Carpenter wrote: > It's Ok to wait weeks. Months is not OK. > > If maintainers are not reading their email then you can try forwarding > the patches through Andrew. > > I feel like I haven't had such a huge problem with this recently... Are > we talking about other arches besides x86 and ARM? My patches are > normally simple is probably part of the difference. Hello Dan, In my e-mail I was referring to the code under drivers/target and drivers/md/dm*. With all due respect, I don't think that Andrew is familiar enough with these code bases to accept patches for these subsystems. Bart. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 15:02 ` Bart Van Assche @ 2017-04-26 15:25 ` James Bottomley 2017-04-26 15:36 ` Mark Brown 0 siblings, 1 reply; 135+ messages in thread From: James Bottomley @ 2017-04-26 15:25 UTC (permalink / raw) To: Bart Van Assche, dan.carpenter Cc: ksummit-discuss, airlied, gregkh, mingo, dledford, davem On April 26, 2017 11:02:39 AM EDT, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote: >On Wed, 2017-04-26 at 11:42 +0300, Dan Carpenter wrote: >> It's Ok to wait weeks. Months is not OK. >> >> If maintainers are not reading their email then you can try >forwarding >> the patches through Andrew. >> >> I feel like I haven't had such a huge problem with this recently... >Are >> we talking about other arches besides x86 and ARM? My patches are >> normally simple is probably part of the difference. > >Hello Dan, > >In my e-mail I was referring to the code under drivers/target and >drivers/md/dm*. With all due respect, I don't think that Andrew is >familiar >enough with these code bases to accept patches for these subsystems. I think what Dan is referring to is that Andrew used to have an override the maintainer role. He'd take a patch and send out the usual email forcing a nak if it shouldn't go upstream. I.e forcing at least a response. You don't need more than a mechanical review to do this because you're challenging the maintainer to respond. James >Bart. >_______________________________________________ >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] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-26 15:25 ` James Bottomley @ 2017-04-26 15:36 ` Mark Brown 0 siblings, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-26 15:36 UTC (permalink / raw) To: James Bottomley Cc: ksummit-discuss, airlied, gregkh, davem, dledford, Bart Van Assche, mingo, dan.carpenter [-- Attachment #1: Type: text/plain, Size: 869 bytes --] On Wed, Apr 26, 2017 at 11:25:12AM -0400, James Bottomley wrote: > On April 26, 2017 11:02:39 AM EDT, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote: > >In my e-mail I was referring to the code under drivers/target and > >drivers/md/dm*. With all due respect, I don't think that Andrew is > >familiar > >enough with these code bases to accept patches for these subsystems. > I think what Dan is referring to is that Andrew used to have an > override the maintainer role. He'd take a patch and send out the > usual email forcing a nak if it shouldn't go upstream. I.e forcing at > least a response. You don't need more than a mechanical review to do > this because you're challenging the maintainer to respond. Or to put it another way at some point if nobody else is doing any work in the area then whoever is becomes our best expert on it. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:50 ` Laurent Pinchart 2017-04-19 19:55 ` James Bottomley @ 2017-04-19 20:14 ` Josh Triplett 2017-04-19 21:30 ` Laurent Pinchart 2017-04-20 5:44 ` Julia Lawall 1 sibling, 2 replies; 135+ messages in thread From: Josh Triplett @ 2017-04-19 20:14 UTC (permalink / raw) To: Laurent Pinchart Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Wed, Apr 19, 2017 at 10:50:15PM +0300, Laurent Pinchart wrote: > Hi Linus, > > On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote: > > On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote: > > > Agreed, for a maintainer summit to be useful, we need to have multiple > > > sides present. Gathering core maintainers with key representatives of the > > > downstream communities around the table is great, but I think we would be > > > missing one category whose opinion is equally important: kernel > > > developers. > > > > > > When everything goes well developers can be represented by their > > > maintainers. That's the case where the process flows smoothly, so there > > > isn't likely to be much to discuss. However, problems occurring in the > > > maintenance process are likely to result in, if not conflicts, at least > > > different views between maintainers and developers, in which case > > > developers won't be represented at the summit. > > > > > > I'm not sure how to handle that. I certainly don't want to increase the > > > number of attendees to include key representatives of developers (and > > > while I'd be very curious to see how they would be selected, I doubt it > > > would work in practice), but I also believe we need to address this class > > > of maintainership issues. > > > > I do agree that it would be a great thing to have a "bitch at > > maintainers" session where developers get to vent frustration at how > > their patches are (or are _not_) accepted by maintainers. > > > > I know we've had issues in the VFS layer, with Al sometimes > > effectively dropping off the intenet for a time, for example. And I'm > > sure it happens elsewhere too, I'm just aware of the VFS side because > > it's one of the areas where I end up personally being a secondary > > maintainer. > > > > But the problem with that "bitch at maintainers" thing is that I can't > > for the life of me come up with a sane small set of people to do that. > > So I don't see it happening ;( > > I currently don't have any good idea to make that happen either, but I'll keep > thinking about it :-) More than bitching at maintainers, I believe that lots > of developers, especially "smaller" or infrequent kernel contributors, are > frustrated by maintainership issues that the related maintainers might not > even be aware of. > > One idea I've been thinking of was to gather constructive feedback (or just > feedback that would then be filtered out of pointless finger-pointing and > bitching) about our maintainers, aggregate it periodically, and submit it to > the maintainers, possibly in an anonymized form. A maintainer summit is > certainly no place to gather that feedback, but could be an occasion to decide > whether such a process would be deemed useful. I for one, while I only > maintain drivers and not whole subsystems, would certainly welcome > constructive criticism in that area. > > > Anyway, I have tried to gather "other groups" that aren't in that > > top-10 maintainers list, but are examples of people "around" the > > maintenance issues: > > > > - stable and linux-next: > > > > Ben Hutchings (stable) > > Stephen Rothwell (linux-next) > > > > - Infrastructure: > > > > Konstantin Ryabitsev (k.org) > > Fengguang Wu (kernel test robot) > > Steven Rostedt (ktest) > > Shuah Khan (tools/testing) > > Thorsten Leemhuis (regression tracking) > > Jonathan Corbet (documentation) > > > > - Security: > > > > Andy Lutomirski (security and core) > > Kees Cook (security) > > James Morris (security subsystem) > > > > - distro people: > > > > Laura Abbott (Fedora) > > Jiri Kosina (MM? JM?) (Suse) > > Rom Lemarchand (Android) > > > > - Hw vendor people? > > - Sponsor people? > > > > but I can't come up with a sane set of "leaf developers" or anything > > like that. We've just got too many. That's obviously a good problem to > > have, but it doesn't fit with the maintainer summit, because unless > > somebody can come up with some kind of prototypical spokesperson for > > that group (and to me, that doesn't seem likely), I don't see how to > > do it. I'd definitely like to see an "issues that affect casual/occasional contributors" discussion; it wouldn't really fit the maintainer summit, but I like James' suggestion of doing it as part of the attached LinuxCon. In terms of framing, though, I'd suggest keeping it focused on "what issues have you personally encountered or directly observed", rather than "what random process ideas do you have". The latter would go downhill very quickly; the former seems much more likely to produce productive feedback on real problems. (It's less important that they come with potential solutions than that the relevant problems get recorded for subsequent consideration.) Will the maintainer summit occur *after* the overlapped conference, or *before*? If after, then it'd be plausible to have a "let's talk about what we heard" session in the maintainer summit. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:14 ` Josh Triplett @ 2017-04-19 21:30 ` Laurent Pinchart 2017-04-20 5:44 ` Julia Lawall 1 sibling, 0 replies; 135+ messages in thread From: Laurent Pinchart @ 2017-04-19 21:30 UTC (permalink / raw) To: Josh Triplett Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller Hi Josh, On Wednesday 19 Apr 2017 13:14:29 Josh Triplett wrote: > On Wed, Apr 19, 2017 at 10:50:15PM +0300, Laurent Pinchart wrote: > > On Wednesday 19 Apr 2017 12:40:47 Linus Torvalds wrote: > >> On Wed, Apr 19, 2017 at 12:25 PM, Laurent Pinchart wrote: > >>> Agreed, for a maintainer summit to be useful, we need to have multiple > >>> sides present. Gathering core maintainers with key representatives of > >>> the downstream communities around the table is great, but I think we > >>> would be missing one category whose opinion is equally important: > >>> kernel developers. > >>> > >>> When everything goes well developers can be represented by their > >>> maintainers. That's the case where the process flows smoothly, so > >>> there isn't likely to be much to discuss. However, problems occurring > >>> in the maintenance process are likely to result in, if not conflicts, > >>> at least different views between maintainers and developers, in which > >>> case developers won't be represented at the summit. > >>> > >>> I'm not sure how to handle that. I certainly don't want to increase > >>> the number of attendees to include key representatives of developers > >>> (and while I'd be very curious to see how they would be selected, I > >>> doubt it would work in practice), but I also believe we need to > >>> address this class of maintainership issues. > >> > >> I do agree that it would be a great thing to have a "bitch at > >> maintainers" session where developers get to vent frustration at how > >> their patches are (or are _not_) accepted by maintainers. > >> > >> I know we've had issues in the VFS layer, with Al sometimes > >> effectively dropping off the intenet for a time, for example. And I'm > >> sure it happens elsewhere too, I'm just aware of the VFS side because > >> it's one of the areas where I end up personally being a secondary > >> maintainer. > >> > >> But the problem with that "bitch at maintainers" thing is that I can't > >> for the life of me come up with a sane small set of people to do that. > >> So I don't see it happening ;( > > > > I currently don't have any good idea to make that happen either, but I'll > > keep thinking about it :-) More than bitching at maintainers, I believe > > that lots of developers, especially "smaller" or infrequent kernel > > contributors, are frustrated by maintainership issues that the related > > maintainers might not even be aware of. > > > > One idea I've been thinking of was to gather constructive feedback (or > > just feedback that would then be filtered out of pointless finger-pointing > > and bitching) about our maintainers, aggregate it periodically, and submit > > it to the maintainers, possibly in an anonymized form. A maintainer summit > > is certainly no place to gather that feedback, but could be an occasion > > to decide whether such a process would be deemed useful. I for one, while > > I only maintain drivers and not whole subsystems, would certainly welcome > > constructive criticism in that area. > > > >> Anyway, I have tried to gather "other groups" that aren't in that > >> top-10 maintainers list, but are examples of people "around" the > >> > >> maintenance issues: > >> - stable and linux-next: > >> Ben Hutchings (stable) > >> Stephen Rothwell (linux-next) > >> > >> - Infrastructure: > >> Konstantin Ryabitsev (k.org) > >> Fengguang Wu (kernel test robot) > >> Steven Rostedt (ktest) > >> Shuah Khan (tools/testing) > >> Thorsten Leemhuis (regression tracking) > >> Jonathan Corbet (documentation) > >> > >> - Security: > >> Andy Lutomirski (security and core) > >> Kees Cook (security) > >> James Morris (security subsystem) > >> > >> - distro people: > >> Laura Abbott (Fedora) > >> Jiri Kosina (MM? JM?) (Suse) > >> Rom Lemarchand (Android) > >> > >> - Hw vendor people? > >> - Sponsor people? > >> > >> but I can't come up with a sane set of "leaf developers" or anything > >> like that. We've just got too many. That's obviously a good problem to > >> have, but it doesn't fit with the maintainer summit, because unless > >> somebody can come up with some kind of prototypical spokesperson for > >> that group (and to me, that doesn't seem likely), I don't see how to > >> do it. > > I'd definitely like to see an "issues that affect casual/occasional > contributors" discussion; it wouldn't really fit the maintainer summit, > but I like James' suggestion of doing it as part of the attached > LinuxCon. It's a good idea, I'd be happy to submit a proposal for such a session and lead it. > In terms of framing, though, I'd suggest keeping it focused on "what > issues have you personally encountered or directly observed", rather > than "what random process ideas do you have". The latter would go > downhill very quickly; the former seems much more likely to produce > productive feedback on real problems. (It's less important that they > come with potential solutions than that the relevant problems get > recorded for subsequent consideration.) I agree. I would extend it to "what issues have you or anyone your represent personally encountered", as I don't expect most of the casual/occasional contributors to attend the conference. > Will the maintainer summit occur *after* the overlapped conference, or > *before*? If after, then it'd be plausible to have a "let's talk about > what we heard" session in the maintainer summit. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:14 ` Josh Triplett 2017-04-19 21:30 ` Laurent Pinchart @ 2017-04-20 5:44 ` Julia Lawall 2017-04-20 8:54 ` Laurent Pinchart 1 sibling, 1 reply; 135+ messages in thread From: Julia Lawall @ 2017-04-20 5:44 UTC (permalink / raw) To: Josh Triplett Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar > I'd definitely like to see an "issues that affect casual/occasional > contributors" discussion; it wouldn't really fit the maintainer summit, > but I like James' suggestion of doing it as part of the attached > LinuxCon. I would be happy to help with the organization of such a thing. julia > In terms of framing, though, I'd suggest keeping it focused on "what > issues have you personally encountered or directly observed", rather > than "what random process ideas do you have". The latter would go > downhill very quickly; the former seems much more likely to produce > productive feedback on real problems. (It's less important that they > come with potential solutions than that the relevant problems get > recorded for subsequent consideration.) > > Will the maintainer summit occur *after* the overlapped conference, or > *before*? If after, then it'd be plausible to have a "let's talk about > what we heard" session in the maintainer summit. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 5:44 ` Julia Lawall @ 2017-04-20 8:54 ` Laurent Pinchart 0 siblings, 0 replies; 135+ messages in thread From: Laurent Pinchart @ 2017-04-20 8:54 UTC (permalink / raw) To: Julia Lawall Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar Hi Julia, On Thursday 20 Apr 2017 07:44:14 Julia Lawall wrote: > > I'd definitely like to see an "issues that affect casual/occasional > > contributors" discussion; it wouldn't really fit the maintainer summit, > > but I like James' suggestion of doing it as part of the attached > > LinuxCon. > > I would be happy to help with the organization of such a thing. Given Daniel Vetter's point that no single conference will cover a wide enough audience, I've been thinking of trying to gather feedback from a larger audience beforehand that could be be used as material for a LinuxCon EU kernel track round table session. If that idea gets traction, help will definitely be more than welcome. > > In terms of framing, though, I'd suggest keeping it focused on "what > > issues have you personally encountered or directly observed", rather > > than "what random process ideas do you have". The latter would go > > downhill very quickly; the former seems much more likely to produce > > productive feedback on real problems. (It's less important that they > > come with potential solutions than that the relevant problems get > > recorded for subsequent consideration.) > > > > Will the maintainer summit occur *after* the overlapped conference, or > > *before*? If after, then it'd be plausible to have a "let's talk about > > what we heard" session in the maintainer summit. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:40 ` Linus Torvalds 2017-04-19 19:45 ` Jens Axboe 2017-04-19 19:50 ` Laurent Pinchart @ 2017-04-19 19:58 ` Konstantin Ryabitsev 2017-04-19 20:20 ` Jiri Kosina 3 siblings, 0 replies; 135+ messages in thread From: Konstantin Ryabitsev @ 2017-04-19 19:58 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Wed, Apr 19, 2017 at 12:40:47PM -0700, Linus Torvalds wrote: > - Infrastructure: > > Konstantin Ryabitsev (k.org) I'll be at the summit (following my usual "shows up to kernel summits even when not invited by privilege of being LF staff" routine). -K ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 19:40 ` Linus Torvalds ` (2 preceding siblings ...) 2017-04-19 19:58 ` Konstantin Ryabitsev @ 2017-04-19 20:20 ` Jiri Kosina 3 siblings, 0 replies; 135+ messages in thread From: Jiri Kosina @ 2017-04-19 20:20 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Wed, 19 Apr 2017, Linus Torvalds wrote: > - distro people: > > Laura Abbott (Fedora) > Jiri Kosina (MM? JM?) (Suse) > Rom Lemarchand (Android) I think that having RHEL kernel maintainer(s) present would be beneficial as well (especially wrt. anything related to stable, as I believe they're as much influenced by it as we are with SLES). I have no idea who that person / those poeple are though. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds 2017-04-18 19:50 ` Takashi Iwai @ 2017-04-18 20:00 ` Dave Airlie 2017-04-18 20:29 ` Laurent Pinchart 2017-04-18 20:38 ` Daniel Vetter 2017-04-18 20:06 ` Serge E. Hallyn ` (7 subsequent siblings) 9 siblings, 2 replies; 135+ messages in thread From: Dave Airlie @ 2017-04-18 20:00 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar > > 11118 David Miller > 6004 Greg KH > 5337 Dave Airlie I am not a number, I AM A FREE MAN. > 5114 Ingo Molnar > 3918 Mauro Carvalho Chehab > 3381 Arnd Bergmann Though it should probably be Arnd sending this considering he's number 6. Sorry couldn't resist, on a more serious note, I'm unlikely to be travelling much this year due to have a baby arriving hopefully in September. I think for drm stuff Daniel Vetter is definitely the best person to have there, if he can make it. Dave. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:00 ` Dave Airlie @ 2017-04-18 20:29 ` Laurent Pinchart 2017-04-18 20:38 ` Daniel Vetter 1 sibling, 0 replies; 135+ messages in thread From: Laurent Pinchart @ 2017-04-18 20:29 UTC (permalink / raw) To: ksummit-discuss Cc: Dave Airlie, Ingo Molnar, Doug Ledford, Greg Kroah-Hartman, David Miller Hi Dave, On Wednesday 19 Apr 2017 06:00:27 Dave Airlie wrote: > > 11118 David Miller > > > > 6004 Greg KH > > 5337 Dave Airlie > > I am not a number, I AM A FREE MAN. > > > 5114 Ingo Molnar > > 3918 Mauro Carvalho Chehab > > 3381 Arnd Bergmann > > Though it should probably be Arnd sending this considering he's number 6. > > Sorry couldn't resist, on a more serious note, I'm unlikely to be > travelling much this year due to have a baby arriving hopefully in > September. > > I think for drm stuff Daniel Vetter is definitely the best person to have > there, if he can make it. I was going to propose that, so I can only second your proposal. Additionally, Daniel has invested lots of time and effort in the actual maintenance process of the DRM subsystem, experimenting with a scheme that is quite unique in the kernel as far as I can tell. For that reason I believe he would be a very good candidate for a maintainer summit. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:00 ` Dave Airlie 2017-04-18 20:29 ` Laurent Pinchart @ 2017-04-18 20:38 ` Daniel Vetter 2017-04-18 20:56 ` Linus Torvalds 1 sibling, 1 reply; 135+ messages in thread From: Daniel Vetter @ 2017-04-18 20:38 UTC (permalink / raw) To: Dave Airlie Cc: Rom Lemarchand, ksummit, Dave Airlie, Greg Kroah-Hartman, Nikula, Jani, Ingo Molnar, Doug Ledford, Sean Paul, David Miller On Tue, Apr 18, 2017 at 10:00 PM, Dave Airlie <airlied@gmail.com> wrote: >> 11118 David Miller >> 6004 Greg KH >> 5337 Dave Airlie > > I am not a number, I AM A FREE MAN. > >> 5114 Ingo Molnar >> 3918 Mauro Carvalho Chehab >> 3381 Arnd Bergmann > > Though it should probably be Arnd sending this considering he's number 6. > > Sorry couldn't resist, on a more serious note, I'm unlikely to be > travelling much this year due to have a baby arriving hopefully in September. > > I think for drm stuff Daniel Vetter is definitely the best person to have there, > if he can make it. It's on the same continent, I'm low on real excuses :-) Depending what we talk about it might be useful to invite Sean Paul and/or Jani Nikula as drm-misc co-maintainers (which really is the drm core + subsystem wide refactorings + misc small drivers in one team nowadays). Sean Paul is also doing ChromeOS from Google's pov, so could bring that perspective. For Android I think it'd be great to have Rom Lemarchand invited (he's google's overall android kernel engineer). Especially on the drm side we've made some great improvements with getting Android stuff running on pure upstream over the last year (and not just as a pile of hacks and shortcuts, but with all the features Android wants). From the infrastructure pov it's essentially mission accomplished afaiui, and the gaps are "just" with some of the drivers (but that's nothing new, upstream open source gfx is still not supported by many vendors unfortunately). Sean, Jani&Rom on cc in case you need their mail address. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:38 ` Daniel Vetter @ 2017-04-18 20:56 ` Linus Torvalds 2017-04-18 21:39 ` Daniel Vetter 0 siblings, 1 reply; 135+ messages in thread From: Linus Torvalds @ 2017-04-18 20:56 UTC (permalink / raw) To: Daniel Vetter Cc: Rom Lemarchand, ksummit, Dave Airlie, Greg Kroah-Hartman, Nikula, Jani, Ingo Molnar, Doug Ledford, Sean Paul, David Miller On Tue, Apr 18, 2017 at 1:38 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > Depending what we talk about it might be useful to invite Sean Paul > and/or Jani Nikula as drm-misc co-maintainers (which really is the drm > core + subsystem wide refactorings + misc small drivers in one team > nowadays). Sean Paul is also doing ChromeOS from Google's pov, so > could bring that perspective. So I'm seeing problems keeping it to a small number. We *will* have to cut. One thing to do is to perhaps require that everybody can talk about at least one particular process pain-point with a suggested improvement. Anybody who doesn't have a painpoint (or whose painpoint is something they don't think can be fixed) could recuse themselves as being "happy". Of course, that's not likely to cut down on numbers _that_ much, so we'll just have to be picky ;) > For Android I think it'd be great to have Rom Lemarchand invited (he's > google's overall android kernel engineer). Good. Side note: people should think about various infrastructure/testing people too So kernel.org, but also things like zero-day etc test labs. I do *not* think we needs tons and tons of developers - unless they have particular maintenance issues. Particular subsystems should aim to have one person per subsystem that can speak for that subsystem, I think, unless there are big reasons why we'd want more and it's particularly contentious. If we end up with 20 developers / maintainers and 10 people who are downstream / stable / infrastructure, I think we'd likely have a reasonable mix. I think that the top-ten list (that was originally cc'd) was reasonably obvious, but it was literallty just a "first round". And it's good to have numbers to show "these are clearly major top-level maintainers", and people on that short-list should at least point to an alternate like DaveA already did. The longer list of 50 was more of a "and here's more people that show up high in git that should then have other reasons to be there". Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:56 ` Linus Torvalds @ 2017-04-18 21:39 ` Daniel Vetter 2017-04-20 19:02 ` Mark Brown 0 siblings, 1 reply; 135+ messages in thread From: Daniel Vetter @ 2017-04-18 21:39 UTC (permalink / raw) To: Linus Torvalds Cc: Rom Lemarchand, ksummit, Dave Airlie, Greg Kroah-Hartman, Nikula, Jani, Ingo Molnar, Doug Ledford, Sean Paul, David Miller On Tue, Apr 18, 2017 at 10:56 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 18, 2017 at 1:38 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >> >> Depending what we talk about it might be useful to invite Sean Paul >> and/or Jani Nikula as drm-misc co-maintainers (which really is the drm >> core + subsystem wide refactorings + misc small drivers in one team >> nowadays). Sean Paul is also doing ChromeOS from Google's pov, so >> could bring that perspective. > > So I'm seeing problems keeping it to a small number. We *will* have to cut. > > One thing to do is to perhaps require that everybody can talk about at > least one particular process pain-point with a suggested improvement. > Anybody who doesn't have a painpoint (or whose painpoint is something > they don't think can be fixed) could recuse themselves as being > "happy". > > Of course, that's not likely to cut down on numbers _that_ much, so > we'll just have to be picky ;) Yeah, Sean/Jani probably only make sense if we bikeshed group maintainer models the entire day. >> For Android I think it'd be great to have Rom Lemarchand invited (he's >> google's overall android kernel engineer). > > Good. > > Side note: people should think about various infrastructure/testing > people too So kernel.org, but also things like zero-day etc test > labs. Hm, we're trying to build up a much more ambitious CI here for drm and intel specifically, but nothing all that interesting yet relevant beyond drm. What could be interesting (but not for the discussion session, more for the general track) is getting our userspace CI team to explain what they do. Except that it runs in userspace the gl drivers are as much low-level driver nonsense as anything else as far as drivers go, and the stuff they're pulling off is seriously impressive. Millions of test runs each day (including pre-merge to stop any regressions before they even get close to the tree), contributor numbers and code size on par with a major Linux subsystem, 100+ different machines and all the fun of testing hw ("yep, that killed all the machines, oops"). A hw testing bof thing for different (driver) subsystems to compare notes might be good, but I'm not sure that'd be useful for the group discussions really. Probably more talking to the audience than what you're aiming for. > I do *not* think we needs tons and tons of developers - unless they > have particular maintenance issues. I do think we overall have some big issues with all the folks who decide not to contribute to upstream but still ship Linux. Android is a big one, but socs in general suffer from this. Like you said in another mail, pointing fingers is no use, least because if we put all the blame on hw vendors there's nothing we can do on our side to improve things :-) Since they don't even show it's hard to find out who'd be a good rep, so probably not much use getting them in as developers (or I have no idea how at least). But I do think we have a big gap here (and e.g. drm for a long time entirely lacked the android perspective in upstream work, until upstream folks + google worked to fix that). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 21:39 ` Daniel Vetter @ 2017-04-20 19:02 ` Mark Brown 0 siblings, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-20 19:02 UTC (permalink / raw) To: Daniel Vetter Cc: Rom Lemarchand, ksummit, Dave Airlie, Greg Kroah-Hartman, Nikula, Jani, David Miller, Doug Ledford, Sean Paul, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 2331 bytes --] On Tue, Apr 18, 2017 at 11:39:22PM +0200, Daniel Vetter wrote: > On Tue, Apr 18, 2017 at 10:56 PM, Linus Torvalds > > Side note: people should think about various infrastructure/testing > > people too So kernel.org, but also things like zero-day etc test > > labs. For kernelci.org the kernel people involved are Kevin Hilman and myself, mainly Kevin. There's also some work on automation of actual test running going on in Linaro intended to end up fulfiling a similar role to the various build/boot bots which should be in a state to talk about usefully by October but I don't want to overpromise. I'll definitely be able to talk about some of the experience with getting things up and running by then. > Hm, we're trying to build up a much more ambitious CI here for drm and > intel specifically, but nothing all that interesting yet relevant > beyond drm. What could be interesting (but not for the discussion > session, more for the general track) is getting our userspace CI team > to explain what they do. Except that it runs in userspace the gl I'm wondering if we should be trying to ge a miniconf together for this stuff, there's a reasonable number of people attacking kernel QA from various angles and there's probably a lot to be gained from sharing ideas and experiences. > A hw testing bof thing for different (driver) subsystems to compare > notes might be good, but I'm not sure that'd be useful for the group > discussions really. Probably more talking to the audience than what > you're aiming for. I think there's a useful conversation to be had there if we do have a good selection of downstream users in the room, not just about hardware testing but more generally about what we're doing upstream around test and how that's translating to our downstreams. How do we make sure that people who are either downstream users or just interested in general kernel testing find out about tests we're using upstream, how to use them and so on? Are the tests we're using useful for them as well as the developers? Ideally testing could be another way to open up interaction with people who haven't been working upstream so much, or if nothing else help raise the quality of out of tree code, but at the minute it seems like we have a discoverability problem. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds 2017-04-18 19:50 ` Takashi Iwai 2017-04-18 20:00 ` Dave Airlie @ 2017-04-18 20:06 ` Serge E. Hallyn 2017-04-18 20:11 ` Greg Kroah-Hartman ` (6 subsequent siblings) 9 siblings, 0 replies; 135+ messages in thread From: Serge E. Hallyn @ 2017-04-18 20:06 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar Quoting Linus Torvalds (torvalds@linux-foundation.org): > - security stuff > > Luto, Kees? James Morris for the security tree? Though it seems to run smoothly, so probably no issues. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (2 preceding siblings ...) 2017-04-18 20:06 ` Serge E. Hallyn @ 2017-04-18 20:11 ` Greg Kroah-Hartman 2017-04-18 20:21 ` Linus Torvalds 2017-04-19 0:22 ` Stephen Rothwell ` (5 subsequent siblings) 9 siblings, 1 reply; 135+ messages in thread From: Greg Kroah-Hartman @ 2017-04-18 20:11 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Doug Ledford, Ingo Molnar, ksummit, David Miller On Tue, Apr 18, 2017 at 11:59:37AM -0700, Linus Torvalds wrote: > - other? I'd recommend Ben Hutchings for the help and work he does with stable kernel releases as well. Those numbers don't show up in your tree, but in the stable releases, he is up there at with the amount of effort and help he provides me, and the users of the trees he maintains (3.2 and 3.16 for Debian). I figure the stable trees do tie into "process improvements" for some discussions. > I'd like the maintainership summit list to be fairly small. Not even > 50 people. Maybe 30. A group that can actually sit in a room for half > a day and talk to each other about the issues they have rather than > being talked to. And talk literally about *process* issues, not about > any particular technical issues within whatever subsystem. Bring up > peeves or wishes for actual process improvements? I'd like to see this happen as well, no technical issues can really be discussed at the kernel summit anymore, we've gotten too big :( thanks, greg k-h ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:11 ` Greg Kroah-Hartman @ 2017-04-18 20:21 ` Linus Torvalds 2017-04-25 15:09 ` Chris Mason 0 siblings, 1 reply; 135+ messages in thread From: Linus Torvalds @ 2017-04-18 20:21 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Dave Airlie, Doug Ledford, Ingo Molnar, ksummit, David Miller On Tue, Apr 18, 2017 at 1:11 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > I'd recommend Ben Hutchings for the help and work he does with stable > kernel releases as well. Those numbers don't show up in your tree, but > in the stable releases, he is up there at with the amount of effort and > help he provides me, and the users of the trees he maintains (3.2 and > 3.16 for Debian). I figure the stable trees do tie into "process > improvements" for some discussions. Absolutely. And as already mentioned, I'd like to extend it further downstream and actually have distro people. Not tons, but to get the discussion going about what works for them and in particular how (if?) we could integrate those closer. Android, of course, being the big elephant in the room. We're not going to solve it, but at least have somebody there talking about _their_ pain points. Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 20:21 ` Linus Torvalds @ 2017-04-25 15:09 ` Chris Mason 0 siblings, 0 replies; 135+ messages in thread From: Chris Mason @ 2017-04-25 15:09 UTC (permalink / raw) To: Linus Torvalds, Greg Kroah-Hartman Cc: Dave Airlie, Doug Ledford, Ingo Molnar, ksummit, David Miller On 04/18/2017 04:21 PM, Linus Torvalds wrote: > On Tue, Apr 18, 2017 at 1:11 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: >> >> I'd recommend Ben Hutchings for the help and work he does with stable >> kernel releases as well. Those numbers don't show up in your tree, but >> in the stable releases, he is up there at with the amount of effort and >> help he provides me, and the users of the trees he maintains (3.2 and >> 3.16 for Debian). I figure the stable trees do tie into "process >> improvements" for some discussions. > > Absolutely. And as already mentioned, I'd like to extend it further > downstream and actually have distro people. Not tons, but to get the > discussion going about what works for them and in particular how (if?) > we could integrate those closer. What kind of questions did you have for the distros? As a semi-distro kernel, we're happy to pitch in with content about bugs, performance, pulling in stable etc, but for the most part things have been smooth lately. It's not completely regression free from a performance point of view, but that's more our fault for not getting our workload specific benchmarks into more hands. We've also had some driver bug drama, but nothing that I would say shows a need for process changes across the board. -chris ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (3 preceding siblings ...) 2017-04-18 20:11 ` Greg Kroah-Hartman @ 2017-04-19 0:22 ` Stephen Rothwell 2017-04-19 13:35 ` Shuah Khan 2017-04-19 20:20 ` James Bottomley ` (4 subsequent siblings) 9 siblings, 1 reply; 135+ messages in thread From: Stephen Rothwell @ 2017-04-19 0:22 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar Hi Linus, On Tue, 18 Apr 2017 11:59:37 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > People who should be involved? I guess I should put my hand up. I suppose I can come up with some process peeves :-) -- Cheers, Stephen Rothwell ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 0:22 ` Stephen Rothwell @ 2017-04-19 13:35 ` Shuah Khan 0 siblings, 0 replies; 135+ messages in thread From: Shuah Khan @ 2017-04-19 13:35 UTC (permalink / raw) To: Stephen Rothwell Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Tue, Apr 18, 2017 at 6:22 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Linus, > > On Tue, 18 Apr 2017 11:59:37 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: >> >> People who should be involved? > > I guess I should put my hand up. I suppose I can come up with some > process peeves :-) Hi Linus and Stephen, I have been seeing more instances of conflicts between kselftest tree and mm, net, and x86. Not surprising. mm, net, amd x86 are the most active areas for selftests and when new tests get added, they usually depend on some feature. As as result, the test has to go through the core tree. It has been resulting in conflicts with the regular activity in kselftest tree. Stephen has been seeing the conflicts when the trees get into linux-next. Maybe something that could be addressed as a general topic or if this is somewhat unique situation (it might be), I can work out a plan offline with the maintainers involved. I don't think this topic would require my presence at the summit. It could be easily discussed on the mailing list. thanks, -- Shuah > > -- > Cheers, > Stephen Rothwell > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (4 preceding siblings ...) 2017-04-19 0:22 ` Stephen Rothwell @ 2017-04-19 20:20 ` James Bottomley 2017-04-19 20:27 ` Jiri Kosina ` (4 more replies) 2017-04-19 20:26 ` Arnd Bergmann ` (3 subsequent siblings) 9 siblings, 5 replies; 135+ messages in thread From: James Bottomley @ 2017-04-19 20:20 UTC (permalink / raw) To: Linus Torvalds, ksummit Cc: Dave Airlie, Greg Kroah-Hartman, Doug Ledford, Ingo Molnar, David Miller On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote: > I'd like the maintainership summit list to be fairly small. Not even > 50 people. Maybe 30. A group that can actually sit in a room for half > a day and talk to each other about the issues they have rather than > being talked to. And talk literally about *process* issues, not about > any particular technical issues within whatever subsystem. Bring up > peeves or wishes for actual process improvements? > > Comments? People who should be involved? Or people who don't have any > particular issues and want to not be involved? I'd like closure on one process issue, if we could achieve it: Maintainer script automation: Quite a few of us have maintainer scripts that send automated email notifications of the status of patches in the tree (mostly to stop people flooding the lists with questions about what happened to their patches). We did a script show and tell at the last kernel summit, but perhaps we could get closure on a couple of issues: 1. Since most people agree that these form of notifications are useful, should we have a standard email for it (or at least a list of things which should be in that email, like commit-id, tree, maintainer, mailing list and the version of the kernel it is expected to be pushed for). 2. Given that we all run ad-hoc infrastructure to produce these emails, could we get a set of blessed scripts up on kernel.org for all comers so we can use the central infrastructure rather than rolling our own. The other things I think it might do us all good is to have a frank session on "tasteful rebasing". We've come around (finally) to the conclusion that rebasing isn't always bad. My own opinion is that rebasing to fix issues in patches (particularly those marked for stable) so they can backport cleanly and atomically. There's also less of a consensus that rebasing to clean up history is a reasonably good thing (provided it's not done just before requesting a pull). However, we have a divergence of opinions not just on whether we should rebase, but what constitutes a tasteful rebase. Just telling people, particularly would be new maintainers, that it's a judgement call always is unhelpful, we could do with putting together some more detailed guidance (assuming we can agree on it). Finally, since Daniel Vetter brought it up, having CI tests is seen as a requirement for most git automation nowadays. I tend to see 0day plus my user base as the CI infrastructure but we should discuss whether this is adequate. I think 0day and linux-next pick up most merge and generic test issues, and no-one has all the hardware to run a true driver CI, so perhaps this is the best we can do, but we should at least discuss whether we want to try to do better. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:20 ` James Bottomley @ 2017-04-19 20:27 ` Jiri Kosina 2017-04-20 10:24 ` Mauro Carvalho Chehab ` (3 subsequent siblings) 4 siblings, 0 replies; 135+ messages in thread From: Jiri Kosina @ 2017-04-19 20:27 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, 19 Apr 2017, James Bottomley wrote: > 1. Since most people agree that these form of notifications are useful, > should we have a standard email for it (or at least a list of things > which should be in that email, like commit-id, tree, maintainer, > mailing list and the version of the kernel it is expected to be > pushed for). > 2. Given that we all run ad-hoc infrastructure to produce these emails, > could we get a set of blessed scripts up on kernel.org for all > comers so we can use the central infrastructure rather than rolling > our own. Just to make sure that we don't repeat a discussion that has already happened, see my proposal from 2015 https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001287.html It didn't receive too much positive traction though. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:20 ` James Bottomley 2017-04-19 20:27 ` Jiri Kosina @ 2017-04-20 10:24 ` Mauro Carvalho Chehab 2017-04-21 8:51 ` Alexandre Belloni 2017-04-21 10:34 ` Michael Ellerman 2017-04-20 16:01 ` Dan Williams ` (2 subsequent siblings) 4 siblings, 2 replies; 135+ messages in thread From: Mauro Carvalho Chehab @ 2017-04-20 10:24 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar Em Wed, 19 Apr 2017 13:20:37 -0700 James Bottomley <James.Bottomley@HansenPartnership.com> escreveu: > 1. Since most people agree that these form of notifications are useful, > should we have a standard email for it (or at least a list of things > which should be in that email, like commit-id, tree, maintainer, > mailing list and the version of the kernel it is expected to be > pushed for). > 2. Given that we all run ad-hoc infrastructure to produce these emails, > could we get a set of blessed scripts up on kernel.org for all > comers so we can use the central infrastructure rather than rolling > our own. I suspect that this very much depends on the way each maintainer handle patches. For subsystems like media, where we use patchwork, notification comes for free with the tool. Thanks, Mauro ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 10:24 ` Mauro Carvalho Chehab @ 2017-04-21 8:51 ` Alexandre Belloni 2017-04-21 8:55 ` Julia Lawall 2017-04-21 8:59 ` Wolfram Sang 2017-04-21 10:34 ` Michael Ellerman 1 sibling, 2 replies; 135+ messages in thread From: Alexandre Belloni @ 2017-04-21 8:51 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller On 20/04/2017 at 07:24:13 -0300, Mauro Carvalho Chehab wrote: > Em Wed, 19 Apr 2017 13:20:37 -0700 > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu: > > > 1. Since most people agree that these form of notifications are useful, > > should we have a standard email for it (or at least a list of things > > which should be in that email, like commit-id, tree, maintainer, > > mailing list and the version of the kernel it is expected to be > > pushed for). > > 2. Given that we all run ad-hoc infrastructure to produce these emails, > > could we get a set of blessed scripts up on kernel.org for all > > comers so we can use the central infrastructure rather than rolling > > our own. > > I suspect that this very much depends on the way each maintainer handle > patches. For subsystems like media, where we use patchwork, notification > comes for free with the tool. > I think patchwork notifications are sent only to people with a patchwork account so this is not enough for subsystems with a lot of drive-by contributors. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 8:51 ` Alexandre Belloni @ 2017-04-21 8:55 ` Julia Lawall 2017-04-21 8:59 ` Wolfram Sang 1 sibling, 0 replies; 135+ messages in thread From: Julia Lawall @ 2017-04-21 8:55 UTC (permalink / raw) To: Alexandre Belloni Cc: James Bottomley, ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Mauro Carvalho Chehab, Doug Ledford, Ingo Molnar On Fri, 21 Apr 2017, Alexandre Belloni wrote: > On 20/04/2017 at 07:24:13 -0300, Mauro Carvalho Chehab wrote: > > Em Wed, 19 Apr 2017 13:20:37 -0700 > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu: > > > > > 1. Since most people agree that these form of notifications are useful, > > > should we have a standard email for it (or at least a list of things > > > which should be in that email, like commit-id, tree, maintainer, > > > mailing list and the version of the kernel it is expected to be > > > pushed for). > > > 2. Given that we all run ad-hoc infrastructure to produce these emails, > > > could we get a set of blessed scripts up on kernel.org for all > > > comers so we can use the central infrastructure rather than rolling > > > our own. > > > > I suspect that this very much depends on the way each maintainer handle > > patches. For subsystems like media, where we use patchwork, notification > > comes for free with the tool. > > > > I think patchwork notifications are sent only to people with a patchwork > account so this is not enough for subsystems with a lot of drive-by > contributors. I receive such notifications and don't have an account, as far as I know. julia > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 8:51 ` Alexandre Belloni 2017-04-21 8:55 ` Julia Lawall @ 2017-04-21 8:59 ` Wolfram Sang 2017-04-21 14:45 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 135+ messages in thread From: Wolfram Sang @ 2017-04-21 8:59 UTC (permalink / raw) To: Alexandre Belloni Cc: James Bottomley, ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Mauro Carvalho Chehab, Doug Ledford, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 307 bytes --] > I think patchwork notifications are sent only to people with a patchwork > account so this is not enough for subsystems with a lot of drive-by > contributors. It can be configured to send emails to everyone. But you need to ask the admin to do that. Jeremy did that for me on ozlabs with the i2c-list. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 8:59 ` Wolfram Sang @ 2017-04-21 14:45 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 135+ messages in thread From: Mauro Carvalho Chehab @ 2017-04-21 14:45 UTC (permalink / raw) To: Wolfram Sang Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, James Bottomley, Doug Ledford, Ingo Molnar Em Fri, 21 Apr 2017 10:59:55 +0200 Wolfram Sang <wsa@the-dreams.de> escreveu: > > I think patchwork notifications are sent only to people with a patchwork > > account so this is not enough for subsystems with a lot of drive-by > > contributors. > > It can be configured to send emails to everyone. But you need to ask the > admin to do that. Jeremy did that for me on ozlabs with the i2c-list. Such setting is enabled for linux-media ML patch posts, at linuxtv.org patchwork server. With that, if one doesn't want e-mails, he/she can create an account at patchwork and opt-out. Thanks, Mauro ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 10:24 ` Mauro Carvalho Chehab 2017-04-21 8:51 ` Alexandre Belloni @ 2017-04-21 10:34 ` Michael Ellerman 2017-04-21 15:06 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 135+ messages in thread From: Michael Ellerman @ 2017-04-21 10:34 UTC (permalink / raw) To: Mauro Carvalho Chehab, James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller Mauro Carvalho Chehab <mchehab@s-opensource.com> writes: > Em Wed, 19 Apr 2017 13:20:37 -0700 > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu: > >> 1. Since most people agree that these form of notifications are useful, >> should we have a standard email for it (or at least a list of things >> which should be in that email, like commit-id, tree, maintainer, >> mailing list and the version of the kernel it is expected to be >> pushed for). >> 2. Given that we all run ad-hoc infrastructure to produce these emails, >> could we get a set of blessed scripts up on kernel.org for all >> comers so we can use the central infrastructure rather than rolling >> our own. > > I suspect that this very much depends on the way each maintainer handle > patches. For subsystems like media, where we use patchwork, notification > comes for free with the tool. AFAIK patchwork can only notify the submitter of the patch, which is OK, but I think it's preferable if the notification goes to the recipient list of the original mail. For example it's quite handy to know when another maintainer has merged a patch, so you don't merge it too, or wonder if you should. cheers ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 10:34 ` Michael Ellerman @ 2017-04-21 15:06 ` Mauro Carvalho Chehab 2017-04-21 23:37 ` James Bottomley 0 siblings, 1 reply; 135+ messages in thread From: Mauro Carvalho Chehab @ 2017-04-21 15:06 UTC (permalink / raw) To: Michael Ellerman Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller Em Fri, 21 Apr 2017 20:34:10 +1000 Michael Ellerman <mpe@ellerman.id.au> escreveu: > Mauro Carvalho Chehab <mchehab@s-opensource.com> writes: > > > Em Wed, 19 Apr 2017 13:20:37 -0700 > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu: > > > >> 1. Since most people agree that these form of notifications are useful, > >> should we have a standard email for it (or at least a list of things > >> which should be in that email, like commit-id, tree, maintainer, > >> mailing list and the version of the kernel it is expected to be > >> pushed for). > >> 2. Given that we all run ad-hoc infrastructure to produce these emails, > >> could we get a set of blessed scripts up on kernel.org for all > >> comers so we can use the central infrastructure rather than rolling > >> our own. > > > > I suspect that this very much depends on the way each maintainer handle > > patches. For subsystems like media, where we use patchwork, notification > > comes for free with the tool. > > AFAIK patchwork can only notify the submitter of the patch, which is OK, > but I think it's preferable if the notification goes to the recipient > list of the original mail. > > For example it's quite handy to know when another maintainer has merged > a patch, so you don't merge it too, or wonder if you should. If another maintainer picks a patch and merge, it will update the patch status. So, refreshing the patch list will update it for you too. Ok, there still the risk of race issues, but, even with email notifications you still have this risk, as you'll get the e-mail only when the other maintainer "publishes" the patches he took on git. Btw, I forgot to say that[1], besides patchwork, we also use a post-receive mailbomb script I wrote several years ago for the patches that are actually applied at the main devel git tree (code enclosed). [1] I don't use myself their notifications. I just store on some random input box, in case someone complains about issues on it. Due to the way we work, I'm the only one that commits at the media development tree. So, I completely forgot about that on my past emails. Thanks, Mauro The following script expects something like this at the git config file: [mailnotify] project = "subsystem_tree" from = my-commits-bounces@example.org to = my-commits@examples.org replyto = subsystem-ml@vger.kernel.org maxsize = 100000 maxmsgs = 100 comitteremail = my@email # url = http://example.org/cgit.cgi/my_tree.git # topic = master debug = 0 #!/usr/bin/perl # # Copyright (c) 2012-2016: Mauro Carvalho Chehab <mchehab@s-opensource.com> # License: GPLv2 # use warnings; use strict; use Getopt::Long; use Date::Parse; use Date::Format; use Sys::Hostname; $ENV{PATH} = '/usr/local/bin:/usr/bin:/bin'; my $program = $0; my @refs; my %parents; # # Retrieve all info from git config # my $project_name = qx(git config mailnotify.project) || "untitled"; my $smtp_server = qx(git config mailnotify.smtpserver) || "localhost"; my $from = qx(git config mailnotify.from) || sprintf('%s@%s', $project_name, hostname()); my $to = qx(git config mailnotify.to) || die("No mail To:"); my $cfgcc = qx(git config mailnotify.cc) || ""; my $replyto = qx(git config mailnotify.replyto) || ""; my $maxsize = qx(git config mailnotify.maxsize) || ""; my $maxmsgs = qx(git config mailnotify.maxmsgs) || 0; my $url = qx(git config mailnotify.url) || ""; my $comitteremail= qx(git config mailnotify.comitteremail) || ""; my $debug = qx(git config mailnotify.debug) || 0; my $debug_dir = qx(git config mailnotify.debugdir) || "queue"; my $mail_cmd = qx(git config mailnotify.mailcmd) || "/usr/sbin/sendmail"; my $topic = qx(git config mailnotify.topic) || ""; GetOptions( "debug" => \$debug, ); $project_name =~ s/\s+$//; $smtp_server =~ s/\s+$//; $from =~ s/\s+$//; $to =~ s/\s+$//; $cfgcc =~ s/\s+$//; $replyto =~ s/\s+$//; $maxsize =~ s/\s+$//; $url =~ s/\s+$//; $comitteremail =~ s/\s+$//; $debug =~ s/\s+$//; $debug_dir =~ s/\s+$//; $mail_cmd =~ s/\s+$//; $topic =~ s/\s+$//; if ($debug && !stat($debug_dir)) { mkdir $debug_dir, 0755 or die "Can't create $debug_dir"; } # # Get old revision, new revision and branch/tag name # my ($oldrev, $newrev, $refname); if (scalar(@ARGV)) { ($oldrev, $newrev, $refname) = @ARGV[ 0 .. 2 ]; } else { my $args = <STDIN>; ($oldrev, $newrev, $refname) = split(" ", $args); } if (!$refname) { $refname = qx(git describe --all $newrev|grep heads/); $refname =~ s,heads/,,; } if (!$oldrev || !$newrev || !$refname) { printf(STDERR "Arguments missing. Can't proceed\n"); exit -1; } printf(STDERR "Running: $0 %s %s %s\n", $oldrev, $newrev, $refname); # Avoid errors like # remote: fatal: Invalid revision range 0000000000000000000000000000000000000000..4dbd68c7a6b13ef1313f51468f1b154d11e5f934 if ($oldrev eq "0000000000000000000000000000000000000000") { printf(STDERR "Warning: using 'master' branch as old rev\n"); $oldrev = "master"; } # # Get the complete revision name # $oldrev = qx(git rev-parse $oldrev); $newrev = qx(git rev-parse $newrev); chomp($oldrev); chomp($newrev); chomp($refname); if ($debug) { printf(STDERR "oldrev:%s\n", $oldrev); printf(STDERR "newrev:%s\n", $newrev); printf(STDERR "refname:%s\n", $refname); } # # Get branch name # my $branch = (split("/", $refname))[-1]; if ($topic ne "") { my $parentbranch = ""; $parentbranch = (split("/", $refname))[-2] if (scalar(split("/", $refname)) > 1); $parentbranch = $refname if (!$parentbranch); printf(STDERR "expected parent branch:%s\n", $topic) if ($debug); printf(STDERR "current parent branch:%s\n", $parentbranch) if ($debug); if ($parentbranch ne $topic) { printf(STDERR "Branch $parentbranch: topic $topic don't generate emails.\n"); exit 0; } } # # get all changesets from $oldrev to $newrev, with their parents # my $n_patches = 0; my $n_ignored = 0; open REF, "git rev-list $oldrev..$newrev|"; while (<REF>) { my $curref = $_; $curref =~ s/\s+$//; if ($comitteremail) { my $comitter = qx(git log --pretty=format:%ce $curref -1); print "$comitter is not maintainer\n" if ($debug && !($comitter =~ m/($comitteremail)/)); if (!($comitter =~ m/($comitteremail)/)) { $n_ignored++; next; } } push @refs, $curref; $n_patches++; } close REF; if ($maxmsgs && ($n_patches > $maxmsgs)) { if ($comitteremail) { my $msg = "Subject: Warning: hook wants to send $n_patches patches!\nFrom: $from\nTo: $comitteremail\n\n"; $msg .= "If this is not an error, please call\n\t" . $program . " $oldrev $newrev $refname\n" . "At the git server\n"; if (!$debug) { open(MAIL, "| $mail_cmd -t"); print MAIL $msg; close MAIL; } else { my $fname = "$debug_dir/error_msg"; open(MAIL, ">$fname") or die "Can't create $fname"; print MAIL $msg; close MAIL; print "Created $fname\n"; } } # Abort script, letting the receive proceed exit 0; } # # Remove merge changesets # print "Generating $n_patches emails.\n" if ($debug); # # Generate one email per changeset # my $count = 1; foreach my $ref (@refs) { my %copy; my $log = ""; # Add mandatory CC $copy{$cfgcc} = "" if ($cfgcc); my $comitter = qx(git log --pretty=format:"%cn <%ce>" $ref -1); my $comitter_email = qx(git log --pretty=format:"%ce" $ref -1); my $comitter_date = qx(git log --pretty=format:"%cd" $ref -1); # Convert date into rfc2822 format $comitter_date = time2str("%a, %d %b %Y %H:%M:%S %z", str2time($comitter_date)); open IN, "git log -1 --pretty=email --stat $ref|"; # Discard initial From line my $dumb=<IN>; my $header; my $is_header=1; while (<IN>) { # Proper handle header continuation fields if ($is_header) { if ($_ eq "\n") { $is_header = 0; } elsif (m/^\s/) { $header =~ s/\n$//; $header .= $_; next; } elsif (m/From:\s*(.*)\n/) { $header .= "From: $comitter\n"; } elsif (m/Subject:\s*(.*)\n/) { my $s = $1; $s =~ s/^\[PATCH\]\s*//; $header .= sprintf("Subject: [git:%s/%s] %s\n", $project_name, $branch, $s); } elsif (m/Date:\s*(.*)\n/) { $header .= sprintf("Date: %s\n", $comitter_date); } else { $header .= $_; } next; } $log .= $_; if (m/(signed-off-by|author|from|accepted-by|tested-by|thanks-to|reviewed-by|cc|acked-by):\s*(.*)\s*\n$/i) { my $sob=$2; my $name; my $email; if ($sob =~ m/\s*(.*)\s*<(.*)>/) { $name = $1; $email = $2; $name =~ s/^\s+//; $name =~ s/\s+$//; $name =~ s/^\"(.*)\"$/$1/; $name="" if ($name =~ m/\@/); } elsif ($sob =~ m/([^\s\<]+\@[^\s+\>]+)/) { $email = $1; $name = ""; } # Don't copy committer/stable next if ($email eq $comitter_email); next if ($email =~ m/stable\@kernel.org/i); $copy{"$email"} = $name if (!exists($copy{"$email"})); } } close IN; my $cc = ""; while (my ($key,$value) = each(%copy) ) { if ($value ne "") { $cc .= ", $value <$key>"; } else { $cc .= ", $key"; } } $cc =~ s/^, //; $cc =~ s/\s+/ /g; my $diff = qx(git show --pretty=format:"" $ref); $header .= "To: $to\n"; $header .= "Cc: $cc\n" if ($cc); if ($replyto) { $header .= "Mail-followup-to: $replyto\n"; $header .= "Forward-to: $replyto\n"; $header .= "Reply-to: $replyto\n"; } my $author = qx(git log -1 --pretty=format:"%an <%ae>" $ref); my $subject = qx(git log -1 --pretty=format:"%s" $ref); my $date = qx(git log -1 --pretty=format:"%ad" $ref); my $comment = "This is an automatic generated email to let you know that the following patch were queued"; if ($url) { $comment .= " at the \n$url tree:\n\n"; } else { $comment .= ":\n\n"; } $comment .= "Subject: $subject\n" . "Author: $author\n" . "Date: $date\n"; my $email = "$header\n$comment\n$log\n---\n\n"; $email .= "$url/commit/?id=$ref\n" if ($url); if ($maxsize && length($diff) > $maxsize) { $diff = "<diff discarded since it is too big>\n" } $email .= $diff; if (!$debug) { open(MAIL, "| $mail_cmd -t"); print MAIL $email; close MAIL; } else { my $fname = "$debug_dir/patch-$count-$ref.patch"; open(MAIL, ">$fname") or die "Can't create $fname"; print MAIL $email; close MAIL; print "Created $fname\n"; } $count++; } printf STDERR "Sent %d emails.\n", $count - 1; printf STDERR "Ignored %d patches that were not committed by $comitteremail.\n", $n_ignored if ($n_ignored); close REF; ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 15:06 ` Mauro Carvalho Chehab @ 2017-04-21 23:37 ` James Bottomley 0 siblings, 0 replies; 135+ messages in thread From: James Bottomley @ 2017-04-21 23:37 UTC (permalink / raw) To: Mauro Carvalho Chehab, Michael Ellerman Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Fri, 2017-04-21 at 12:06 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Apr 2017 20:34:10 +1000 > Michael Ellerman <mpe@ellerman.id.au> escreveu: > > > Mauro Carvalho Chehab <mchehab@s-opensource.com> writes: > > > > > Em Wed, 19 Apr 2017 13:20:37 -0700 > > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu: > > > > > > > 1. Since most people agree that these form of notifications > > > > are useful, should we have a standard email for it (or at > > > > least a list of things which should be in that email, like > > > > commit-id, tree, maintainer, mailing list and the version of > > > > the kernel it is expected to be pushed for). > > > > 2. Given that we all run ad-hoc infrastructure to produce > > > > these emails, could we get a set of blessed scripts up on > > > > kernel.org for all comers so we can use the central > > > > infrastructure rather than rolling our own. > > > > > > I suspect that this very much depends on the way each maintainer > > > handle patches. For subsystems like media, where we use > > > patchwork, notification comes for free with the tool. > > > > AFAIK patchwork can only notify the submitter of the patch, which > > is OK, but I think it's preferable if the notification goes to the > > recipient list of the original mail. > > > > For example it's quite handy to know when another maintainer has > > merged a patch, so you don't merge it too, or wonder if you should. > > If another maintainer picks a patch and merge, it will update the > patch status. So, refreshing the patch list will update it for you > too. > > Ok, there still the risk of race issues, but, even with email > notifications you still have this risk, as you'll get the e-mail > only when the other maintainer "publishes" the patches he took > on git. > > Btw, I forgot to say that[1], besides patchwork, we also use a > post-receive mailbomb script I wrote several years ago for the > patches that are actually applied at the main devel git tree (code > enclosed). Yes, mine is a special git tree on hansenpartnership.com that does the same thing. I'd rather like not to run git on my cloud system, hence the rather selfish question about whether we could do it on kernel.org. > [1] I don't use myself their notifications. I just store on some > random input box, in case someone complains about issues on it. > Due to the way we work, I'm the only one that commits at the media > development tree. So, I completely forgot about that on my past > emails. > > Thanks, > Mauro > > The following script expects something like this at the git config > file: Looking at yours, it doesn't seem to handle either rebasing or patch removing. Attached is mine, which does both. A patch update gets both a remove and an add patch. I do the same correct committer check (did have a cockup several years ago where I updated the wrong branch and sent out several hundred emails before I managed to kill it). Mine's also complicated by the fact I used to run a pending tree where I put patches that I thought needed reviewing but the maintainer hadn't yet reviewed them. The script would also send out periodic nag mails about reviews. it's designed to operate on my trees, which carry both a <branch> and a <branch>-base branch which is used to work out what patches actually belong to me. I should really switch over to using git-mergebase for this, but haven't got around to it yet. James --- #!/usr/bin/perl # # An example hook script to mail out commit update information. # It can also blocks tags that aren't annotated. # Called by git-receive-pack with arguments: refname sha1-old sha1-new # # To enable this hook, make this file executable by "chmod +x update". # # Config # ------ # hooks.mailinglist # This is the list that all pushes will go to; leave it blank to not send # emails frequently. The log email will list every log entry in full between # the old ref value and the new ref value. # hooks.announcelist # This is the list that all pushes of annotated tags will go to. Leave it # blank to just use the mailinglist field. The announce emails list the # short log summary of the changes since the last annotated tag # hooks.allowunannotated # This boolean sets whether unannotated tags will be allowed into the # repository. By default they won't be. # # Notes # ----- # All emails have their subjects prefixed with "[SCM]" to aid filtering. # All emails include the headers "X-Git-Refname", "X-Git-Oldrev", # "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and info. # --- Constants chomp($cwd=`pwd`); require $cwd.'/hooks/update-variables.pl' || die; # branches which comprise the base of the tree (i.e. ones not to # report commits in) for a push of master. The default is 'linus'. # 'merge-base' only gets used when the tree has to be based on a # non-standard tree because of conflicts %BRANCHES = ( 'merge-base' => 1, 'linus' => 1, ); %IGNORED_BRANCHES = ( 'for-next' => 1, 'for-linus' => 1, 'master' => 1, ); @IGNOREDCC = ( 'stable@kernel.org', 'stable@vger.kernel.org', ); %EMAILTO = ( 'James.Bottomley@HansenPartnership.com' => 1, 'martin.petersen@oracle.com' => 1, ); # --- Command line $refname = $ARGV[0]; if ($refname =~ m|^refs/tags/|) { $refname =~ s|^refs/tags/||; $tag = 1; } else { $refname =~ s|^refs/heads/||; } $oldrev=$ARGV[1]; $newrev=$ARGV[2]; # --- Safety check if ($ENV{'GIT_DIR'} eq '') { print STDERR "Don't run this script from the command line."; print STDERR " (if you want, you could supply GIT_DIR then run"; print STDERR " $0 <ref> <oldrev> <newrev>)"; exit 1; } if ($refname eq '' || $oldrev eq '' || $newrev eq '') { print STDERR "Usage: $0 <ref> <oldrev> <newrev>"; exit 1; } if ($tag) { chomp(@t = `git cat-file tag $newrev`); foreach (@t) { if (/^tagger (.*>)/) { $recipients = $1; break; } } if (!$recipients) { print STDERR "Can't find a tagger in $refname\n"; exit 1; } if (%EMAILTO) { $EMAILTO{$recipients} = 1; $recipients = join(', ', keys(%EMAILTO)); } chomp(@_ = `git merge-base $newrev master`); $oldrev = $_[0]; chomp(@commitlist = `git rev-list $newrev ^$oldrev`); @commitlog = (); foreach $commit (@commitlist) { chomp(@_ = `git show --oneline $commit`); push @commitlog, $_[0]; } @email = ( # Generate header "From: James Bottomley <James.Bottomley\@HansenPartnership.com>", "To: $recipients", "Subject: Tag $revname added to tree ${TREE}", "X-Git-Oldrev: $oldrev", "X-Git-Newrev: $newrev", "X-Git-Tree: $TREEHDR", "", "Your tag $refname", "", "Containing:", ); push @email, @commitlog; push @email, ( "", "has been added to the $TREETYPE $TREE tree", "", "You can find it here:", "", "http://git.kernel.org/?p=linux/kernel/git/jejb/${TREE}.git;a=tag;h=$newrev", "", $WHENPUSH, "", "James Bottomley", "", "P.S. If you find this email unwanted, set up a procmail rule junking on", "the header:", "", "X-Git-Tree: $TREEHDR", "", ); open(EMAIL, "| /usr/sbin/sendmail -t") || die; print EMAIL join("\n", @email); close(EMAIL); #print STDERR join("\n", @email); print STDERR "Email sent to: $recipients\n"; exit 0; } if ($IGNORED_BRANCHES{$refname}) { print STDERR "Branch $refname ignored, not generating email\n"; exit 0; } if ($refname =~ m/-base$/ || $BRANCHES{$refname}) { print STDERR "Updating base branch\n"; exit 0; } $branch = ''; chomp(@branches = `git branch`); if ($refname eq 'master') { foreach $b (keys(%BRANCHES)) { next if (!grep(/^..$b/,@branches)); $branch = $b; last; } } elsif (grep(/^..${refname}-base/,@branches)) { $branch = $refname.'-base'; } if (!$branch) { print STDERR 'Upstream head has no needed bases: '.join(" ", @BRANCHES)." or ${refname}-base\n"; exit 1; } if ($oldrev eq '0000000000000000000000000000000000000000' ) { print STDERR "Creating new branch $refname\n"; exit 0; } @commitlist = (); chomp(@revlist = `git rev-list --no-merges $newrev ^$oldrev ^$branch`); chomp(@cherrylist = `git cherry $refname $newrev`); # don't annoy Linus guard: check that all of the cherrylist is actually mine foreach $commit (@revlist) { # - prefix means the commit from $newrev is already in $branch next if (grep(/^- $commit/, @cherrylist)); push @commitlist, $commit; $_ = `git log --pretty='format:%cn' $commit^..$commit`; next if (/^James Bottomley/); next if (/^Christoph Hellwig/); next if (/^Martin K. Petersen/); print STDERR "ERROR: commit $commit is not yours\n"; print STDERR "ERROR: $_\n"; exit 1; } $WHENPUSH = $WHENPUSHED{$refname}; if (!$WHENPUSH) { $WHENPUSH = $WHENPUSHED{'default'}; } $NEEDACKS = $NEEDACKS{$refname}; #find the deleted commits and add them to the commit list chomp(@deletelist = `git cherry $newrev $refname $branch`); foreach $_ (@deletelist) { next if (!m/^\+ /); # found a delete; add it to the email list keeping the + prefix push @commitlist, $_; } foreach $commit (@commitlist) { if ($commit =~ m/^\+ /) { $commit = substr($commit,2); $delete = 1; $EMAILPREFIX="Patch dropped from ${TREE}: "; } else { $delete = 0; $EMAILPREFIX="Patch added to ${TREE}: "; } @email = (); $author = ''; if (%EMAILTO) { %recipients = %EMAILTO; } %ackrequired = (); $subject = ''; outer: foreach $_ (`git log $commit^..$commit`) { if (/^ / && $subject eq '') { chomp($subject = substr($_, 4)); } elsif (/^Author: / && $author eq '') { chomp($author = substr($_, 8)); $recipients{$author} = 1; } elsif (/^ signed-off-by: /i) { chomp($a = substr($_, 19)); $recipients{$a} = 1; delete $ackrequired{$a}; } elsif (/^ reviewed-by: /i) { chomp($a = substr($_, 16)); $recipients{$a} = 1; delete $ackrequired{$a}; } elsif(/^ acked-by: /i) { chomp($a = substr($_, 14)); $recipients{$a} = 1; delete $ackrequired{$a}; } elsif(/^ tested-by: /i) { chomp($a = substr($_, 15)); $recipients{$a} = 1; delete $ackrequired{$a}; } elsif(/^ reported-by: /i) { chomp($a = substr($_, 17)); $recipients{$a} = 1; delete $ackrequired{$a}; } elsif (/^ cc: /i) { chomp($a = substr($_, 8)); foreach(@IGNOREDCC) { if ($a =~ m/$_/) { next outer; } } $recipients{$a} = 1; $ackrequired{$a} = 1; } } # I don't want to receive email #delete $recipients{'James Bottomley <James.Bottomley@SteelEye.com>'}; # --- Email (all stdout will be the email) $recipients = join(', ', keys(%recipients)); #$recipients = 'James.Bottomley@HansenPartnership.com'; @email = ( # Generate header "From: James Bottomley <James.Bottomley\@HansenPartnership.com>", "To: $recipients", "Subject: ${EMAILPREFIX} $subject", "X-Git-Oldrev: $oldrev", "X-Git-Newrev: $newrev", "X-Git-Tree: $TREEHDR", "", # body goes here "Your commit:", ); chomp(@commitlog = `git log $commit^..$commit`); # get rid of the commit/author/date header shift @commitlog; shift @commitlog; shift @commitlog; push @email, @commitlog; if ($delete) { push @email, ( "", "has been dropped from the $TREETYPE $TREE tree", "On branch \"$refname\"", "", ); } else { push @email, ( "", "has been added to the $TREETYPE $TREE tree", "On branch \"$refname\"", "You can find it here:", "", "http://git.kernel.org/?p=linux/kernel/git/jejb/${TREE}.git;a=commit;h=$commit", "", $WHENPUSH, ); } if ($NEEDACKS && %ackrequired) { push @email, ( "", "This patch is pending because it requires ACKs from:", "", join("\n", keys(%ackrequired)), "", "If those are received it may be moved into one of the upstream SCSI trees", ); } push @email, ( "", "James Bottomley", "", "P.S. If you find this email unwanted, set up a procmail rule junking on", "the header:", "", "X-Git-Tree: $TREEHDR", "", ); open(EMAIL, "| /usr/sbin/sendmail -t") || die; print EMAIL join("\n", @email); close(EMAIL); #print STDERR join("\n", @email); print STDERR "Email sent to: $recipients\n"; } exit 0 --- The update-variables.pl looks like this: $_=`git tag -l 'v*'`; chomp; my ($major, $minor) = (0,0); foreach $_ (split /\n/) { my ($lmajor, $lminor) = m/v(\d+)\.(\d+)-rc\d$/; ($major, $minor) = ($lmajor, $lminor) if ($lmajor > $major || ($lmajor == $major && $lminor > $minor)); } $_=`git tag -l 'v${major}.${minor}'`; # $_ is populated if we're in a merge window $minor++ if ($_); my $cur = $major.'.'.$minor; my $next = $major.'.'.($minor + 1); $TREE = "scsi"; $TREETYPE = "upstream"; $TREEHDR = 'SCSI'; %WHENPUSHED = ( "default" => "This patch is scheduled to be pushed when the merge window opens for $next", "fixes" => "This patch is scheduled to be pushed for $cur", "pending" => "This patch is not on an upstream branch", "postmerge" => "This patch is scheduled to be pushed when the merge window opens for $next but depends on another tree which must be pushed first", ); %NEEDACKS = ( "pending" => 1 ); 1; ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:20 ` James Bottomley 2017-04-19 20:27 ` Jiri Kosina 2017-04-20 10:24 ` Mauro Carvalho Chehab @ 2017-04-20 16:01 ` Dan Williams 2017-04-21 11:07 ` Michael Ellerman 2017-04-21 23:19 ` Bjorn Helgaas 4 siblings, 0 replies; 135+ messages in thread From: Dan Williams @ 2017-04-20 16:01 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, Apr 19, 2017 at 1:20 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote: [..] > Finally, since Daniel Vetter brought it up, having CI tests is seen as > a requirement for most git automation nowadays. I tend to see 0day > plus my user base as the CI infrastructure but we should discuss > whether this is adequate. I think 0day and linux-next pick up most > merge and generic test issues, and no-one has all the hardware to run a > true driver CI, so perhaps this is the best we can do, but we should at > least discuss whether we want to try to do better. I think we can do better with approaches like cmock [1] to go attack code paths that would otherwise require specific hardware. The pain points I see around testing are, how to discover and run available tests for a given subsystem, and how to determine a "clean" run. For example, xfstests depend on not only the kernel, but utilities as well. Tracking all the moving pieces, tests, kernel and utilities is a non-trivial amount of overhead. [1]: http://www.throwtheswitch.org/cmock/ ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:20 ` James Bottomley ` (2 preceding siblings ...) 2017-04-20 16:01 ` Dan Williams @ 2017-04-21 11:07 ` Michael Ellerman 2017-04-21 17:06 ` Mauro Carvalho Chehab 2017-04-21 23:19 ` Bjorn Helgaas 4 siblings, 1 reply; 135+ messages in thread From: Michael Ellerman @ 2017-04-21 11:07 UTC (permalink / raw) To: James Bottomley, Linus Torvalds, ksummit Cc: Dave Airlie, Greg Kroah-Hartman, Doug Ledford, Ingo Molnar, David Miller James Bottomley <James.Bottomley@HansenPartnership.com> writes: > On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote: >> I'd like the maintainership summit list to be fairly small. Not even >> 50 people. Maybe 30. A group that can actually sit in a room for half >> a day and talk to each other about the issues they have rather than >> being talked to. And talk literally about *process* issues, not about >> any particular technical issues within whatever subsystem. Bring up >> peeves or wishes for actual process improvements? >> >> Comments? People who should be involved? Or people who don't have any >> particular issues and want to not be involved? > > I'd like closure on one process issue, if we could achieve it: > > Maintainer script automation: Quite a few of us have maintainer scripts > that send automated email notifications of the status of patches in the > tree (mostly to stop people flooding the lists with questions about > what happened to their patches). We did a script show and tell at the > last kernel summit, but perhaps we could get closure on a couple of > issues: > > 1. Since most people agree that these form of notifications are useful, > should we have a standard email for it (or at least a list of things > which should be in that email, like commit-id, tree, maintainer, > mailing list and the version of the kernel it is expected to be > pushed for). We could have suggestions, I'm not sure an actual standard is feasible given the differences in the processes people use. > 2. Given that we all run ad-hoc infrastructure to produce these emails, > could we get a set of blessed scripts up on kernel.org for all > comers so we can use the central infrastructure rather than rolling > our own. This would be great. But is there actually a set of scripts out there which are in sufficiently good state that we could ask the kernel.org admins to run them? If the mail sending happens on kernel.org how do the scripts know which mail to respond to for a given commit? It could be in the commit message somehow, but that's ugly. My scripts use git-notes for that sort of metadata, which works quite well, so maybe that's an option. Or maybe you're thinking that they don't reply to the original patch, they just mail the author? There's also times when you push commits that have already been responded to by someone else (ie. a submaintainer), so there'd need to be some way to flag that. And then obviously the case where you fast forward to Linus' branch, you don't want to send mails for all those commits :) Another thing that's nice is to only send one mail when you merge a big series, which complicates things a bit more. Anyway a slightly old version of my terrible scripts are here, if anyone wants to have a look. https://github.com/mpe/patchwork-scripts They rely on having the mbox of the original patch in .git/patchwork, and they don't actually send the mails, just generate them, allowing some manual tweaking before sending. cheers ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 11:07 ` Michael Ellerman @ 2017-04-21 17:06 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 135+ messages in thread From: Mauro Carvalho Chehab @ 2017-04-21 17:06 UTC (permalink / raw) To: Michael Ellerman Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, James Bottomley, Doug Ledford, Ingo Molnar Em Fri, 21 Apr 2017 21:07:24 +1000 Michael Ellerman <mpe@ellerman.id.au> escreveu: > James Bottomley <James.Bottomley@HansenPartnership.com> writes: > > > On Tue, 2017-04-18 at 11:59 -0700, Linus Torvalds wrote: > >> I'd like the maintainership summit list to be fairly small. Not even > >> 50 people. Maybe 30. A group that can actually sit in a room for half > >> a day and talk to each other about the issues they have rather than > >> being talked to. And talk literally about *process* issues, not about > >> any particular technical issues within whatever subsystem. Bring up > >> peeves or wishes for actual process improvements? > >> > >> Comments? People who should be involved? Or people who don't have any > >> particular issues and want to not be involved? > > > > I'd like closure on one process issue, if we could achieve it: > > > > Maintainer script automation: Quite a few of us have maintainer scripts > > that send automated email notifications of the status of patches in the > > tree (mostly to stop people flooding the lists with questions about > > what happened to their patches). We did a script show and tell at the > > last kernel summit, but perhaps we could get closure on a couple of > > issues: > > > > 1. Since most people agree that these form of notifications are useful, > > should we have a standard email for it (or at least a list of things > > which should be in that email, like commit-id, tree, maintainer, > > mailing list and the version of the kernel it is expected to be > > pushed for). > > We could have suggestions, I'm not sure an actual standard is feasible > given the differences in the processes people use. > > > 2. Given that we all run ad-hoc infrastructure to produce these emails, > > could we get a set of blessed scripts up on kernel.org for all > > comers so we can use the central infrastructure rather than rolling > > our own. > > This would be great. > > But is there actually a set of scripts out there which are in > sufficiently good state that we could ask the kernel.org admins to run > them? > > If the mail sending happens on kernel.org how do the scripts know which > mail to respond to for a given commit? It could be in the commit message > somehow, but that's ugly. My scripts use git-notes for that sort of > metadata, which works quite well, so maybe that's an option. > > Or maybe you're thinking that they don't reply to the original patch, > they just mail the author? > > There's also times when you push commits that have already been > responded to by someone else (ie. a submaintainer), so there'd need to > be some way to flag that. And then obviously the case where you fast > forward to Linus' branch, you don't want to send mails for all those > commits :) The script I posted on my past e-mail handles it using two algorithms: - It checks for the committer e-mail. If the patch isn't committed by me, it skips the patch; - It prevents sending more than a certain number of e-mails, with is configurable at git config file. That prevents mailbomb patches that I committed via some other tree (like edac). With those two rules, automatic mailbomb actually looks OK. > Another thing that's nice is to only send one mail when you merge a big > series, which complicates things a bit more. That would be interesting, but prevents pushing the actual patch. In our case, we mailbomb patches also to a mailing list, allowing others to review and comment on patches actually applied. Thanks, Mauro ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:20 ` James Bottomley ` (3 preceding siblings ...) 2017-04-21 11:07 ` Michael Ellerman @ 2017-04-21 23:19 ` Bjorn Helgaas 4 siblings, 0 replies; 135+ messages in thread From: Bjorn Helgaas @ 2017-04-21 23:19 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, Apr 19, 2017 at 3:20 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > I'd like closure on one process issue, if we could achieve it: > > Maintainer script automation: Quite a few of us have maintainer scripts > that send automated email notifications of the status of patches in the > tree (mostly to stop people flooding the lists with questions about > what happened to their patches). We did a script show and tell at the > last kernel summit, but perhaps we could get closure on a couple of > issues: I wasn't at the last summit, and there's a lot of room for improvement in this area of my life. Is this show and tell available anywhere? > 1. Since most people agree that these form of notifications are useful, > should we have a standard email for it (or at least a list of things > which should be in that email, like commit-id, tree, maintainer, > mailing list and the version of the kernel it is expected to be > pushed for). > 2. Given that we all run ad-hoc infrastructure to produce these emails, > could we get a set of blessed scripts up on kernel.org for all > comers so we can use the central infrastructure rather than rolling > our own. > > The other things I think it might do us all good is to have a frank > session on "tasteful rebasing". We've come around (finally) to the > conclusion that rebasing isn't always bad. My own opinion is that > rebasing to fix issues in patches (particularly those marked for > stable) so they can backport cleanly and atomically. There's also less > of a consensus that rebasing to clean up history is a reasonably good > thing (provided it's not done just before requesting a pull). However, > we have a divergence of opinions not just on whether we should rebase, > but what constitutes a tasteful rebase. Just telling people, > particularly would be new maintainers, that it's a judgement call > always is unhelpful, we could do with putting together some more > detailed guidance (assuming we can agree on it). I'm interested in this, too. I update topic branches regularly to add acks, fix typos, fold in fixes discovered before merging to Linus, etc. I assume that as long as it hasn't been merged, doing that as separate patches would just be clutter. But maybe I'm making life difficult for contributors who consume those branches. I almost always apply patches from email (as opposed to pulling via git), and I typically base the topic branches on -rc1 or -rc2, because that makes it simple for me to do these updates. Bjorn ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (5 preceding siblings ...) 2017-04-19 20:20 ` James Bottomley @ 2017-04-19 20:26 ` Arnd Bergmann 2017-04-20 8:53 ` Daniel Vetter 2017-04-21 11:03 ` Alexandre Belloni 2017-04-19 21:05 ` Andy Lutomirski ` (2 subsequent siblings) 9 siblings, 2 replies; 135+ messages in thread From: Arnd Bergmann @ 2017-04-19 20:26 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, ksummit, Dave Airlie, Greg Kroah-Hartman, Doug Ledford, David Miller On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > What I _would_ like to see is those top maintainers suggest > "submaintainer" names. Particularly Davem, since he doesn't tend to > want to come to the kernel summit, and being at the top of the list > that's a kind of big gaping hole. I guess we haven't had all that many > _problems_ within networking, but if we talk maintainership issues, > it's certainly a bit odd if it's entirely lacking. We have both core > networking and network drivers that both fall under "davem" as far as > my pull statistics go. For ARM, the work also tends to be fairly spread out across many people, with few of us being overly important. [I think that while Olof and I had similar shares of work in pulling in patches, I ended up in one of the top spots because I happened to send more pull requests during the last year, and I also did quite a bit of kernel stuff outside of arch/arm.] So while there is no need for having lots of ARM platform maintainers, I would like to see some of the people that I interact with that also work with a larger number of other maintainers: - One of the device tree maintainers (Rob Herring, Frank Rowand, Mark Rutland), they inevitably deal with almost all device driver writers at some point - One of the CLK subsystem maintainers (Michael Turquette, Stephen Boyd), they also interact with a large number of subsystem and platform maintainers, and we have had some disagreements particularly when dealing with three subsystems (clk, arm-soc and a device driver) in one patch series. - One or two ARM platform maintainers, ideally one that also maintains another kernel subsystem. The platforms with the most changes are usually sunxi (Maxime Ripard), OMAP (Tony Lindgren), Renesas (Simon Horman), Broadcom (Florian Fainelli), Qualcomm (Andy Gross) and Freescale (Shawn Guo). - One or two of the ARM32/ARM64 architecture people: Russell King, Catalin Marinas, Will Deacon. Arnd ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:26 ` Arnd Bergmann @ 2017-04-20 8:53 ` Daniel Vetter 2017-04-20 11:30 ` Arnd Bergmann 2017-04-20 19:26 ` Mark Brown 2017-04-21 11:03 ` Alexandre Belloni 1 sibling, 2 replies; 135+ messages in thread From: Daniel Vetter @ 2017-04-20 8:53 UTC (permalink / raw) To: Arnd Bergmann Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> What I _would_ like to see is those top maintainers suggest >> "submaintainer" names. Particularly Davem, since he doesn't tend to >> want to come to the kernel summit, and being at the top of the list >> that's a kind of big gaping hole. I guess we haven't had all that many >> _problems_ within networking, but if we talk maintainership issues, >> it's certainly a bit odd if it's entirely lacking. We have both core >> networking and network drivers that both fall under "davem" as far as >> my pull statistics go. > > For ARM, the work also tends to be fairly spread out across many > people, with few of us being overly important. [I think that while Olof and > I had similar shares of work in pulling in patches, I ended up in one of > the top spots because I happened to send more pull requests during > the last year, and I also did quite a bit of kernel stuff outside of > arch/arm.] > > So while there is no need for having lots of ARM platform maintainers, > I would like to see some of the people that I interact with that also > work with a larger number of other maintainers: > > - One of the device tree maintainers (Rob Herring, Frank Rowand, > Mark Rutland), they inevitably deal with almost all device driver > writers at some point > > - One of the CLK subsystem maintainers (Michael Turquette, > Stephen Boyd), they also interact with a large number of > subsystem and platform maintainers, and we have had some > disagreements particularly when dealing with three subsystems > (clk, arm-soc and a device driver) in one patch series. > > - One or two ARM platform maintainers, ideally one that also > maintains another kernel subsystem. The platforms with the most > changes are usually sunxi (Maxime Ripard), OMAP (Tony > Lindgren), Renesas (Simon Horman), Broadcom (Florian > Fainelli), Qualcomm (Andy Gross) and Freescale (Shawn Guo). > > - One or two of the ARM32/ARM64 architecture people: Russell > King, Catalin Marinas, Will Deacon. I think discussing arm-soc vs. driver subsystem flows would be good. Not a personal gripe of mine, but since I seem to be volunteered to rep drm overall a topic I have to bring in. We have plenty of cross maintainer patch series and depencies in drm, and the usual way we handle this is: - get it reviewed by everyone - then either get acks from the subsystems (when it's smaller patches, or well separated from other stuff going on in that subsystem) to merge it all through one tree (usually the one with the most patches in the series) - or create a topic branch and send around cross-subsystem pull requests. This works rather well, and we have a bunch of cross-subsystem depencies we handle each month this way with trees outside of drm, not including the coordination needs within drm among different drm trees. In arm-soc this seems to not happen, and instead your nice bisectable patch series which implements an overall feature is split up into a bunch of trees, which then get forwarded independently. That means the bisect benefits are out, testing gets harder (either you have your own integration tree, or try to test linux-next and suffer), and sometimes even the final patches to enable something or switch drivers for a platform need to be delayed by an entire release. Related to this is that there's no single stop-shop for driver submissions for the arm platform stuff, but it's all split up. Fairly often that means at least one of the maintainers doesn't like your face, is on vacation or leave, burried for other reasons, or at least has slightly different ideas about what color the bikeshed needs to be. That makes contributions for people who just want to get their driver for a given platform in a pain. For non-arm-soc ecosystem drivers things seem a lot more relaxed and efficient and sensible. The notable thing is that it's _not_ DT (at least mostly), because Rob Herring is doing an awesome job getting gpu related DT patches reviewed and generally acks all of them for merging throught the drm trees. But even for DT I'm concerned about the bus factor of 1 we defacto have for gpu drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 8:53 ` Daniel Vetter @ 2017-04-20 11:30 ` Arnd Bergmann 2017-04-20 13:46 ` Daniel Vetter 2017-04-20 19:26 ` Mark Brown 1 sibling, 1 reply; 135+ messages in thread From: Arnd Bergmann @ 2017-04-20 11:30 UTC (permalink / raw) To: Daniel Vetter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Thu, Apr 20, 2017 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: > I think discussing arm-soc vs. driver subsystem flows would be good. > Not a personal gripe of mine, but since I seem to be volunteered to > rep drm overall a topic I have to bring in. We have plenty of cross > maintainer patch series and depencies in drm, and the usual way we > handle this is: > - get it reviewed by everyone > - then either get acks from the subsystems (when it's smaller patches, > or well separated from other stuff going on in that subsystem) to > merge it all through one tree (usually the one with the most patches > in the series) > - or create a topic branch and send around cross-subsystem pull requests. > > This works rather well, and we have a bunch of cross-subsystem > depencies we handle each month this way with trees outside of drm, not > including the coordination needs within drm among different drm trees. > > In arm-soc this seems to not happen, and instead your nice bisectable > patch series which implements an overall feature is split up into a > bunch of trees, which then get forwarded independently. That means the > bisect benefits are out, testing gets harder (either you have your own > integration tree, or try to test linux-next and suffer), and sometimes > even the final patches to enable something or switch drivers for a > platform need to be delayed by an entire release. Do you know of a specific example where this happened? We try to take a lot of care to ensure that each of the branches is bisectable, so it sounds like we (or our downstream developers) were missing something in the QA testing if this failed repeatedly. When I'm aware of a change that requires cross-tree coordination (e.g. a Kconfig symbol gets renamed, or a DT binding changes in an incompatible way), we usually try to come up with a way to do the change differently (e.g. add have multiple Kconfig symbols with the same meaning for a release or two, or find a way to make the binding backwards compatible after all), but we also frequently give Acks for merging stuff in arch/arm, or have a shared tree that gets merged through both a driver subsystem and one of our branches. > Related to this is that there's no single stop-shop for driver > submissions for the arm platform stuff, but it's all split up. Fairly > often that means at least one of the maintainers doesn't like your > face, is on vacation or leave, burried for other reasons, or at least > has slightly different ideas about what color the bikeshed needs to > be. That makes contributions for people who just want to get their > driver for a given platform in a pain. This is in a large part by design: we used to have a problem with dozens of platforms in arch/arm/mach-* doing the same things slightly differently, each of them being controlled only by a single platform maintainer. We have over time introduced many separate subsystems (irqchip, rtc, gpio, pinctrl, iommu, clk, timer, led, pci, cpufreq, cpuidle, pwm, dmaengine, phy, regulator, memory, nvmem, thermal, hwspinlock, mailbox, reset, and probably a few others), and moved code out of our responsibility into those subsystems that are maintained independently. The subsystem maintainers have a much better understanding of how things work in their domain across all the platforms, so we get better review than we had in the 2.6 days when this all fell upon a single architecture or platform maintainer. You still typically have to get new changes approved by both a platform maintainer (for your SoC) as well as the subsystem maintainer, and I consider that a good idea. The price for it however is that anyone working on a single platform has to deal with a multitude of git trees, and things become harder at the point where they interact, especially when you migrate a platform from old-style board files to devicetree. Fortunately these days, the vast majority of changes we deal with are purely additions of new drivers or features, so there are rarely any actual cross-tree dependencies or conflicts any more: The only things that we merge through arm-soc most of the time are defconfig additions, dts file changes and sometimes new Kconfig symbols for new platforms, and all of them can come in any order without causing regressions. Arnd ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 11:30 ` Arnd Bergmann @ 2017-04-20 13:46 ` Daniel Vetter 2017-04-24 14:02 ` Olof Johansson 2017-04-24 16:17 ` Linus Walleij 0 siblings, 2 replies; 135+ messages in thread From: Daniel Vetter @ 2017-04-20 13:46 UTC (permalink / raw) To: Arnd Bergmann Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Thu, Apr 20, 2017 at 1:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Apr 20, 2017 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >> On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> I think discussing arm-soc vs. driver subsystem flows would be good. >> Not a personal gripe of mine, but since I seem to be volunteered to >> rep drm overall a topic I have to bring in. We have plenty of cross >> maintainer patch series and depencies in drm, and the usual way we >> handle this is: >> - get it reviewed by everyone >> - then either get acks from the subsystems (when it's smaller patches, >> or well separated from other stuff going on in that subsystem) to >> merge it all through one tree (usually the one with the most patches >> in the series) >> - or create a topic branch and send around cross-subsystem pull requests. >> >> This works rather well, and we have a bunch of cross-subsystem >> depencies we handle each month this way with trees outside of drm, not >> including the coordination needs within drm among different drm trees. >> >> In arm-soc this seems to not happen, and instead your nice bisectable >> patch series which implements an overall feature is split up into a >> bunch of trees, which then get forwarded independently. That means the >> bisect benefits are out, testing gets harder (either you have your own >> integration tree, or try to test linux-next and suffer), and sometimes >> even the final patches to enable something or switch drivers for a >> platform need to be delayed by an entire release. > > Do you know of a specific example where this happened? We try > to take a lot of care to ensure that each of the branches is bisectable, > so it sounds like we (or our downstream developers) were missing > something in the QA testing if this failed repeatedly. > > When I'm aware of a change that requires cross-tree coordination > (e.g. a Kconfig symbol gets renamed, or a DT binding changes > in an incompatible way), we usually try to come up with a way to > do the change differently (e.g. add have multiple Kconfig symbols > with the same meaning for a release or two, or find a way to > make the binding backwards compatible after all), but we also > frequently give Acks for merging stuff in arch/arm, or have a shared > tree that gets merged through both a driver subsystem and one > of our branches. Not "broken bisecting" as in if you bisect you might hit a broken configuration, but reduced usefulness for figuring out bugs. If a bigger feature or change in driver that also comes with some clk/irqchip/whatever changes, or an entire rewrite, then I've heard of examples where the splitting across trees meant that your bisect would end up in one of the merge commits (whichever is the last one that adds the missing piece) instead of somewhere in the middle like if the original patch series would have landed as linear history in a topic branch. Might just be good to chat a bit about when exactly a topic branch is called for, and when exactly merging through each separate tree is better. I get a bit the feeling that merging through separate trees is done to make sure platforms use all the infrastructure correctly (which is the topic below), but it seems like DT managed to get there without merging things stricly only through a DT tree. >> Related to this is that there's no single stop-shop for driver >> submissions for the arm platform stuff, but it's all split up. Fairly >> often that means at least one of the maintainers doesn't like your >> face, is on vacation or leave, burried for other reasons, or at least >> has slightly different ideas about what color the bikeshed needs to >> be. That makes contributions for people who just want to get their >> driver for a given platform in a pain. > > This is in a large part by design: we used to have a problem with > dozens of platforms in arch/arm/mach-* doing the same things > slightly differently, each of them being controlled only by a single > platform maintainer. We have over time introduced many separate > subsystems (irqchip, rtc, gpio, pinctrl, iommu, clk, timer, led, pci, > cpufreq, cpuidle, pwm, dmaengine, phy, regulator, memory, > nvmem, thermal, hwspinlock, mailbox, reset, and probably a few > others), and moved code out of our responsibility into those > subsystems that are maintained independently. > > The subsystem maintainers have a much better understanding > of how things work in their domain across all the platforms, so > we get better review than we had in the 2.6 days when this all > fell upon a single architecture or platform maintainer. You still > typically have to get new changes approved by both a platform > maintainer (for your SoC) as well as the subsystem maintainer, > and I consider that a good idea. The price for it however is that > anyone working on a single platform has to deal with a > multitude of git trees, and things become harder at the point > where they interact, especially when you migrate a platform > from old-style board files to devicetree. > > Fortunately these days, the vast majority of changes we deal > with are purely additions of new drivers or features, so there > are rarely any actual cross-tree dependencies or conflicts any > more: The only things that we merge through arm-soc most > of the time are defconfig additions, dts file changes and > sometimes new Kconfig symbols for new platforms, and all > of them can come in any order without causing regressions. Just to clarify: I'm very impressed with all the infrastructure the arm-soc folks manged to pull off, and I understand why you have them all and how it works. But having bigger groups for bus factor reasons and making it easier for totally new contributions to not get completely lost and leave in frustration might be good. DRM is also fairly big nowadays, with piles of helpers and libraries for different things (not quite at the level of arm-soc yet), but we try to give new driver submissions one person who handles the entire thing, and pulls in acks from specific experts as needed. Still needs some working out and maybe formalizing the process more (atm it's mostly coordination over irc), but with group maintiners for all areas and load balancing between them that seems to work fairly well. While still making sure that new drivers use all the latest helpers and best practices (we add them constantly, so almost always something that could be simplified by using a new thing just merge 1-2 months ago). And sharing knowledge about all these things amongst maintainers and reviewers. And yeah, rewriting an entire platform from the old to the new model is a different beast on its own, this here is just from the pov of submitting individual drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 13:46 ` Daniel Vetter @ 2017-04-24 14:02 ` Olof Johansson 2017-04-24 16:17 ` Linus Walleij 1 sibling, 0 replies; 135+ messages in thread From: Olof Johansson @ 2017-04-24 14:02 UTC (permalink / raw) To: Daniel Vetter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Thu, Apr 20, 2017 at 6:46 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > On Thu, Apr 20, 2017 at 1:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Thu, Apr 20, 2017 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >>> On Wed, Apr 19, 2017 at 10:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>> I think discussing arm-soc vs. driver subsystem flows would be good. >>> Not a personal gripe of mine, but since I seem to be volunteered to >>> rep drm overall a topic I have to bring in. We have plenty of cross >>> maintainer patch series and depencies in drm, and the usual way we >>> handle this is: >>> - get it reviewed by everyone >>> - then either get acks from the subsystems (when it's smaller patches, >>> or well separated from other stuff going on in that subsystem) to >>> merge it all through one tree (usually the one with the most patches >>> in the series) >>> - or create a topic branch and send around cross-subsystem pull requests. >>> >>> This works rather well, and we have a bunch of cross-subsystem >>> depencies we handle each month this way with trees outside of drm, not >>> including the coordination needs within drm among different drm trees. >>> >>> In arm-soc this seems to not happen, and instead your nice bisectable >>> patch series which implements an overall feature is split up into a >>> bunch of trees, which then get forwarded independently. That means the >>> bisect benefits are out, testing gets harder (either you have your own >>> integration tree, or try to test linux-next and suffer), and sometimes >>> even the final patches to enable something or switch drivers for a >>> platform need to be delayed by an entire release. >> >> Do you know of a specific example where this happened? We try >> to take a lot of care to ensure that each of the branches is bisectable, >> so it sounds like we (or our downstream developers) were missing >> something in the QA testing if this failed repeatedly. >> >> When I'm aware of a change that requires cross-tree coordination >> (e.g. a Kconfig symbol gets renamed, or a DT binding changes >> in an incompatible way), we usually try to come up with a way to >> do the change differently (e.g. add have multiple Kconfig symbols >> with the same meaning for a release or two, or find a way to >> make the binding backwards compatible after all), but we also >> frequently give Acks for merging stuff in arch/arm, or have a shared >> tree that gets merged through both a driver subsystem and one >> of our branches. > > Not "broken bisecting" as in if you bisect you might hit a broken > configuration, but reduced usefulness for figuring out bugs. If a > bigger feature or change in driver that also comes with some > clk/irqchip/whatever changes, or an entire rewrite, then I've heard of > examples where the splitting across trees meant that your bisect would > end up in one of the merge commits (whichever is the last one that > adds the missing piece) instead of somewhere in the middle like if the > original patch series would have landed as linear history in a topic > branch. > > Might just be good to chat a bit about when exactly a topic branch is > called for, and when exactly merging through each separate tree is > better. I get a bit the feeling that merging through separate trees is > done to make sure platforms use all the infrastructure correctly > (which is the topic below), but it seems like DT managed to get there > without merging things stricly only through a DT tree. You're likely to see this even with topic branches, for example you won't see issues with a new driver until said driver is turned on in the config. I do agree that it's frustrating to debug issues that only show up once two branches are merged though. For DT, the main effort has been in trying to make sure that bindings get reviewed before they go in, but there hasn't been much stepping-on-toes between the bindings. The main reason we want ARM DT updates merged through our tree, is that we've seen some horrible messes caused when there hasn't been coordination between driver and platform developers/maintainers, and we've seen some horrible conflict messes in the past. Also, since DT is supposed to be about describing the hardware of the system, it's so far seemed appropriate to have the platform maintainer merge it and do so through our tree. Still, every few releases we see conflicts reported by Stephen where some driver maintainer has picked up DT contents and it conflicts across trees. Often it happens with new platform maintainers not knowing to avoid sending these out, and driver maintainers happily applying them. We usually just bring it up quietly with the people affected, since most conflicts are simple add/add context cases. It would be nice to get a bit more awareness of our preferences out to other maintainers as well. It might have been 5+ years by now, but we also still have some scars from where ARM platforms had some serious issues due to lack of coordination, so we're still conservative in this area. DT is high-volume contents that's really convenient to have in-tree, but if we start seeing frequent conflicts pressure will build up to get it out of the kernel repo. I'd be happy to meet and discuss this, and I'd be happy to get more feedback from you on what you're ideally looking for in person or over email. My name hasn't showed up much on the short lists for reasons Arnd mentioned, but I'm likely to be around for hallway track to discuss. >>> Related to this is that there's no single stop-shop for driver >>> submissions for the arm platform stuff, but it's all split up. Fairly >>> often that means at least one of the maintainers doesn't like your >>> face, is on vacation or leave, burried for other reasons, or at least >>> has slightly different ideas about what color the bikeshed needs to >>> be. That makes contributions for people who just want to get their >>> driver for a given platform in a pain. >> >> This is in a large part by design: we used to have a problem with >> dozens of platforms in arch/arm/mach-* doing the same things >> slightly differently, each of them being controlled only by a single >> platform maintainer. We have over time introduced many separate >> subsystems (irqchip, rtc, gpio, pinctrl, iommu, clk, timer, led, pci, >> cpufreq, cpuidle, pwm, dmaengine, phy, regulator, memory, >> nvmem, thermal, hwspinlock, mailbox, reset, and probably a few >> others), and moved code out of our responsibility into those >> subsystems that are maintained independently. >> >> The subsystem maintainers have a much better understanding >> of how things work in their domain across all the platforms, so >> we get better review than we had in the 2.6 days when this all >> fell upon a single architecture or platform maintainer. You still >> typically have to get new changes approved by both a platform >> maintainer (for your SoC) as well as the subsystem maintainer, >> and I consider that a good idea. The price for it however is that >> anyone working on a single platform has to deal with a >> multitude of git trees, and things become harder at the point >> where they interact, especially when you migrate a platform >> from old-style board files to devicetree. >> >> Fortunately these days, the vast majority of changes we deal >> with are purely additions of new drivers or features, so there >> are rarely any actual cross-tree dependencies or conflicts any >> more: The only things that we merge through arm-soc most >> of the time are defconfig additions, dts file changes and >> sometimes new Kconfig symbols for new platforms, and all >> of them can come in any order without causing regressions. > > Just to clarify: I'm very impressed with all the infrastructure the > arm-soc folks manged to pull off, and I understand why you have them > all and how it works. But having bigger groups for bus factor reasons > and making it easier for totally new contributions to not get > completely lost and leave in frustration might be good. Agreed. We're starting to see a few new platforms again, and getting more info on how to do these things might be useful. Maybe it's time for another ARM-SoC talk at a conference to refer to, the last ones weren't really aimed at new contributors, and are somewhat outdated. > DRM is also > fairly big nowadays, with piles of helpers and libraries for different > things (not quite at the level of arm-soc yet), but we try to give new > driver submissions one person who handles the entire thing, and pulls > in acks from specific experts as needed. Still needs some working out > and maybe formalizing the process more (atm it's mostly coordination > over irc), but with group maintiners for all areas and load balancing > between them that seems to work fairly well. While still making sure > that new drivers use all the latest helpers and best practices (we add > them constantly, so almost always something that could be simplified > by using a new thing just merge 1-2 months ago). And sharing knowledge > about all these things amongst maintainers and reviewers. DRM is a really active subsystem, and it definitely has some challenges due to it (like all highly active areas of development). I think it's one of the driver subsystems that touch core kernel code the most, something that's easily noticed when trying to port DRM to older/newer kernels. It seems to me that you can really tell when a subsystem is maintained by people who have to worry about back/forward-ports and when someone mostly worries about making it work as well as possible on the current kernel, and change whatever's needed to make that happen. Neither is better than the other in my opinion, but they obviously have different tradeoffs. > And yeah, rewriting an entire platform from the old to the new model > is a different beast on its own, this here is just from the pov of > submitting individual drivers. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 13:46 ` Daniel Vetter 2017-04-24 14:02 ` Olof Johansson @ 2017-04-24 16:17 ` Linus Walleij 2017-04-24 17:29 ` Olof Johansson 2017-04-25 9:10 ` Lee Jones 1 sibling, 2 replies; 135+ messages in thread From: Linus Walleij @ 2017-04-24 16:17 UTC (permalink / raw) To: Daniel Vetter, Lee Jones Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > Might just be good to chat a bit about when exactly a topic branch is > called for, and when exactly merging through each separate tree is > better. I get a bit the feeling that merging through separate trees is > done to make sure platforms use all the infrastructure correctly > (which is the topic below), but it seems like DT managed to get there > without merging things stricly only through a DT tree. What has been mentioned about Kconfig symbols being merged in one place and then turned on in a merge commit is just part of it really. To me the big pain is always API/file dependencies. The typical case where we have to have a immutable topic branch is when there is a new API (or just a header file really) added in one patch and then a slew of patches need that API are sprinkled all over the kernel, so they by necessity need to base on this nexus commit. Essentially it happens when developers need an API from subsystem A in place to do changes in subsystems B, C, D... Also they seldom have patience to wait for a kernel cycle before making use of the API change, instead one finger on the fastforward button at all times. (I don't blame them, I am one of them.) Typical cases: <linux/mfd/*.h> <dt-bindings/*.h> I think Lee Jones could contribute to discussions around this, as he's had the painful job to coordinate queue and quite a few of these hurdles due to the nature of MFD as a connection nexus for misc. One thing he does is queue an immutable topic branch, announce it and let all affected subsystems pull it in, so that we (e.g. GPIO) can then refactor or apply local fixes in "our" subsystem from that point, even during the development cycle. It is pretty neat. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-24 16:17 ` Linus Walleij @ 2017-04-24 17:29 ` Olof Johansson 2017-04-24 17:58 ` Mark Brown 2017-04-25 9:10 ` Lee Jones 1 sibling, 1 reply; 135+ messages in thread From: Olof Johansson @ 2017-04-24 17:29 UTC (permalink / raw) To: Linus Walleij Cc: ksummit, Dave Airlie, David Miller, Doug Ledford, Greg Kroah-Hartman, Ingo Molnar On Mon, Apr 24, 2017 at 9:17 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > >> Might just be good to chat a bit about when exactly a topic branch is >> called for, and when exactly merging through each separate tree is >> better. I get a bit the feeling that merging through separate trees is >> done to make sure platforms use all the infrastructure correctly >> (which is the topic below), but it seems like DT managed to get there >> without merging things stricly only through a DT tree. > > What has been mentioned about Kconfig symbols being merged in > one place and then turned on in a merge commit is just part of it > really. To me the big pain is always API/file dependencies. > > The typical case where we have to have a immutable topic branch > is when there is a new API (or just a header file really) added in one > patch and then a slew of patches need that API are sprinkled all over > the kernel, so they by necessity need to base on this nexus commit. > > Essentially it happens when developers need an API from subsystem > A in place to do changes in subsystems B, C, D... Also they seldom have > patience to wait for a kernel cycle before making use of the API change, > instead one finger on the fastforward button at all times. (I don't blame them, > I am one of them.) > > Typical cases: > <linux/mfd/*.h> > <dt-bindings/*.h> > > I think Lee Jones could contribute to discussions around this, as he's > had the painful job to coordinate queue and quite a few of these hurdles > due to the nature of MFD as a connection nexus for misc. > > One thing he does is queue an immutable topic branch, announce it and > let all affected subsystems pull it in, so that we (e.g. GPIO) can then > refactor or apply local fixes in "our" subsystem from that point, even during > the development cycle. It is pretty neat. Yeah, Lee has been doing a good job there (even though we always double-check about immutable branches to make the producer aware that we've picked it up). The clk maintainers (Mike/Stephen) have been doing a good job too where they tend to apply patches on a per-driver branch that they keep immutable. In the clk case we've been pushing back against the "add a branch dependency just to add one numerical define use" that has been common for incremental changes that affect clk and DT contents, instead asking people to revisit with a follow-up patch either right after -rc1 or next release. -Olof ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-24 17:29 ` Olof Johansson @ 2017-04-24 17:58 ` Mark Brown 0 siblings, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-24 17:58 UTC (permalink / raw) To: Olof Johansson Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller [-- Attachment #1: Type: text/plain, Size: 1245 bytes --] On Mon, Apr 24, 2017 at 10:29:02AM -0700, Olof Johansson wrote: > On Mon, Apr 24, 2017 at 9:17 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > > One thing he does is queue an immutable topic branch, announce it and > > let all affected subsystems pull it in, so that we (e.g. GPIO) can then > > refactor or apply local fixes in "our" subsystem from that point, even during > > the development cycle. It is pretty neat. > Yeah, Lee has been doing a good job there (even though we always > double-check about immutable branches to make the producer aware that Yeah, I do the same thing where that comes up (mainly for regulator and sometimes regmap). Seems to work pretty well. > we've picked it up). The clk maintainers (Mike/Stephen) have been > doing a good job too where they tend to apply patches on a per-driver > branch that they keep immutable. That's what I do as well. It's especially helpful if you discover a need to do a cross merge after things have been applied, it means that you probably already have something fairly sensible to send to the other maintainers involved and don't need to rebase things or duplicate commits. Before I started doing this those things were always painful, now I just need to sign a tag. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-24 16:17 ` Linus Walleij 2017-04-24 17:29 ` Olof Johansson @ 2017-04-25 9:10 ` Lee Jones 2017-04-29 21:00 ` Daniel Vetter 1 sibling, 1 reply; 135+ messages in thread From: Lee Jones @ 2017-04-25 9:10 UTC (permalink / raw) To: Linus Walleij Cc: ksummit, Dave Airlie, Ingo Molnar, Doug Ledford, Greg Kroah-Hartman, David Miller On Mon, 24 Apr 2017, Linus Walleij wrote: > On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > Might just be good to chat a bit about when exactly a topic branch is > > called for, and when exactly merging through each separate tree is > > better. I get a bit the feeling that merging through separate trees is > > done to make sure platforms use all the infrastructure correctly > > (which is the topic below), but it seems like DT managed to get there > > without merging things stricly only through a DT tree. > > The typical case where we have to have a immutable topic branch > is when there is a new API (or just a header file really) added in one > patch and then a slew of patches need that API are sprinkled all over > the kernel, so they by necessity need to base on this nexus commit. [...] > I think Lee Jones could contribute to discussions around this, as he's > had the painful job to coordinate queue and quite a few of these hurdles > due to the nature of MFD as a connection nexus for misc. > > One thing he does is queue an immutable topic branch, announce it and > let all affected subsystems pull it in, so that we (e.g. GPIO) can then > refactor or apply local fixes in "our" subsystem from that point, even during > the development cycle. It is pretty neat. Multi-Function Devices (drivers/mfd) can waive a complicated web of cross-subsystem/interdependent function calls, resources and time sensitive H/W initialisation constraints. Thus, when working with such devices, the Maintainers of the children devices and I must work together to avoid disruption to the user experience. Our chosen method, or at least the one which causes the least pain, is immutable branches. Pull-requests to immutable branches are an invaluable tool when coordination between 2 or more maintainers is required. The use-case does not always allow it, but we do try to encapsulate all of the dependencies within a single branch, thus minimising the chance of conflict during the merge-window. My MFD pull-request to Linus can contain between 1 and 7 immutable tags. Although common place, immutable branches are still treated as the last resort. If patches can be taken via their respective subsystem trees without fear of disruption, they are. Contributors often attempt to have their *new* cross-subsystem functionality taken in via a single tree (requiring an immutable branch), purely because it's convenient and the merge-time becomes deterministic, but we do not allow that unless there are hard/unavoidable build-time dependencies. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-25 9:10 ` Lee Jones @ 2017-04-29 21:00 ` Daniel Vetter 2017-04-29 21:39 ` James Bottomley ` (2 more replies) 0 siblings, 3 replies; 135+ messages in thread From: Daniel Vetter @ 2017-04-29 21:00 UTC (permalink / raw) To: Lee Jones Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller [Back from a bit of vacation, so I'm just jumping into the middle of the cross-subsystem/invariant topic branch discussion. I read all the other mails, but this seems most relevant.] On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> wrote: > Although common place, immutable branches are still treated as the > last resort. If patches can be taken via their respective subsystem > trees without fear of disruption, they are. Contributors often > attempt to have their *new* cross-subsystem functionality taken in via > a single tree (requiring an immutable branch), purely because it's > convenient and the merge-time becomes deterministic, but we do not > allow that unless there are hard/unavoidable build-time dependencies. Honest question, why exactly? At a quick ignorant glance this seems to trade contributor time against maintainer time, which in my opinion means you should ramp up your maintainer training and mentoring to have much more maintainer time available and make contributing to upstream more attractive. But drm != other subsystems, I'd like to hear more of why you picked this tradeoff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-29 21:00 ` Daniel Vetter @ 2017-04-29 21:39 ` James Bottomley 2017-04-30 12:45 ` Mark Brown 2017-04-30 19:12 ` Olof Johansson 2017-05-02 8:09 ` Lee Jones 2 siblings, 1 reply; 135+ messages in thread From: James Bottomley @ 2017-04-29 21:39 UTC (permalink / raw) To: Daniel Vetter, Lee Jones Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Sat, 2017-04-29 at 23:00 +0200, Daniel Vetter wrote: > [Back from a bit of vacation, so I'm just jumping into the middle of > the cross-subsystem/invariant topic branch discussion. I read all the > other mails, but this seems most relevant.] > > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> > wrote: > > Although common place, immutable branches are still treated as the > > last resort. If patches can be taken via their respective > > subsystem trees without fear of disruption, they are. Contributors > > often attempt to have their *new* cross-subsystem functionality > > taken in via a single tree (requiring an immutable branch), purely > > because it's convenient and the merge-time becomes deterministic, > > but we do not allow that unless there are hard/unavoidable build > > -time dependencies. > > Honest question, why exactly? Because if you take a patch for, say SCSI, through your tree it potentially becomes a big pain for everyone if we pick up a conflict. The conflict isn't seen until linux-next finds it because the conflicting patch is in your tree not mine (and SCSI contributors mostly build against the SCSI tree) then Stephen has to come up with a merge and we have to validate it and send it on to Linus as a recommendation at merge window time. Another good reason for not taking patches to subsystems outside yours are that you're not necessarily an expert in whatever subsystem it is, so a patch would get a better review cycle going through the correct subsystem tree. There are good reasons to take on this pain, like the conflicting patch depends on something else that's in your tree but not in mine, so there's no clean way to split it up and thus it makes sense to take it through your tree and just handle the conflicts as they arise but absent that the rule should be that patches to a subsystem go through its tree. > At a quick ignorant glance this seems to trade contributor time > against maintainer time, which in my opinion means you should ramp up > your maintainer training and mentoring to have much more maintainer > time available and make contributing to upstream more attractive. But > drm != other subsystems, I'd like to hear more of why you picked this > tradeoff. It's not just maintainer time ... taking patches outside your subsystem should always have a good reason because it's not just a training/tooling issue; you're potentially impacting some other subsystem by this action. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-29 21:39 ` James Bottomley @ 2017-04-30 12:45 ` Mark Brown 0 siblings, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-30 12:45 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Ingo Molnar, Doug Ledford, Greg Kroah-Hartman, David Miller [-- Attachment #1: Type: text/plain, Size: 1740 bytes --] On Sat, Apr 29, 2017 at 02:39:31PM -0700, James Bottomley wrote: > On Sat, 2017-04-29 at 23:00 +0200, Daniel Vetter wrote: > > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> > > > Although common place, immutable branches are still treated as the > > > last resort. If patches can be taken via their respective > > > subsystem trees without fear of disruption, they are. Contributors > > > often attempt to have their *new* cross-subsystem functionality > > > taken in via a single tree (requiring an immutable branch), purely > > > because it's convenient and the merge-time becomes deterministic, > > > but we do not allow that unless there are hard/unavoidable build > > > -time dependencies. > > Honest question, why exactly? [Snip a bunch of good reasons from James] > > At a quick ignorant glance this seems to trade contributor time > > against maintainer time, which in my opinion means you should ramp up > > your maintainer training and mentoring to have much more maintainer > > time available and make contributing to upstream more attractive. But > > drm != other subsystems, I'd like to hear more of why you picked this > > tradeoff. > It's not just maintainer time ... taking patches outside your subsystem > should always have a good reason because it's not just a > training/tooling issue; you're potentially impacting some other > subsystem by this action. The other thing is that no matter how good the maintainers are at handling cross tree stuff there's always going to be some cost to the submitter even if it's just delays as the maintainers talk to each other. The less coordination is needed the more chance there is that things will go smoothly. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-29 21:00 ` Daniel Vetter 2017-04-29 21:39 ` James Bottomley @ 2017-04-30 19:12 ` Olof Johansson 2017-05-02 8:09 ` Lee Jones 2 siblings, 0 replies; 135+ messages in thread From: Olof Johansson @ 2017-04-30 19:12 UTC (permalink / raw) To: Daniel Vetter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Sat, Apr 29, 2017 at 2:00 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > [Back from a bit of vacation, so I'm just jumping into the middle of > the cross-subsystem/invariant topic branch discussion. I read all the > other mails, but this seems most relevant.] > > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> wrote: >> Although common place, immutable branches are still treated as the >> last resort. If patches can be taken via their respective subsystem >> trees without fear of disruption, they are. Contributors often >> attempt to have their *new* cross-subsystem functionality taken in via >> a single tree (requiring an immutable branch), purely because it's >> convenient and the merge-time becomes deterministic, but we do not >> allow that unless there are hard/unavoidable build-time dependencies. > > Honest question, why exactly? > > At a quick ignorant glance this seems to trade contributor time > against maintainer time, which in my opinion means you should ramp up > your maintainer training and mentoring to have much more maintainer > time available and make contributing to upstream more attractive. But > drm != other subsystems, I'd like to hear more of why you picked this > tradeoff. As mentioned already, we've seen too many messes caused by multiple people stepping on each other. When you merge a mixed-contents branch through another subsystem you have to gamble on anyone else not touching anything near it. Worst case possible is refactorings of code made by people at the same time, with the almost-as-bad-case of one side refactoring, the other one adding something new. And given how refactoring-happy DRM is, I'm extremely hesitant to see ARM contents merged through there. Another reason for that is that it's pretty common to have for example media and graphics handled by separate teams from main platform code (both in corporate land as well as on the community side). Having two separate teams work on the same piece of code means that even though _you_ say it's OK to merge through a different tree, the platform maintainer on the other team might have different plans for that code. Yes, there's some overhead in dealing with this. Most of it is pushed down to the per-platform level, so there's no need to coordinate all the way up the maintainer path in many cases. Main exception is usually new contributors/platforms where we keep an extra eye on things as new people get used to their roles, build up experience, etc. -Olof ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-29 21:00 ` Daniel Vetter 2017-04-29 21:39 ` James Bottomley 2017-04-30 19:12 ` Olof Johansson @ 2017-05-02 8:09 ` Lee Jones 2 siblings, 0 replies; 135+ messages in thread From: Lee Jones @ 2017-05-02 8:09 UTC (permalink / raw) To: Daniel Vetter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller On Sat, 29 Apr 2017, Daniel Vetter wrote: > [Back from a bit of vacation, so I'm just jumping into the middle of > the cross-subsystem/invariant topic branch discussion. I read all the > other mails, but this seems most relevant.] > > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org> wrote: > > Although common place, immutable branches are still treated as the > > last resort. If patches can be taken via their respective subsystem > > trees without fear of disruption, they are. Contributors often > > attempt to have their *new* cross-subsystem functionality taken in via > > a single tree (requiring an immutable branch), purely because it's > > convenient and the merge-time becomes deterministic, but we do not > > allow that unless there are hard/unavoidable build-time dependencies. > > Honest question, why exactly? > > At a quick ignorant glance this seems to trade contributor time > against maintainer time, which in my opinion means you should ramp up > your maintainer training and mentoring to have much more maintainer > time available and make contributing to upstream more attractive. But > drm != other subsystems, I'd like to hear more of why you picked this > tradeoff. It looks like James et. al. have provided some pretty good technical reasons as to why taking patches via their associated subsystem repos is *always* preferred, so I will not labour this point. However I will provide a frank answer to your trading Maintainer for Contributor time query. To be candid, you're right we do that, and it's exactly what we should be doing. There are a couple of reasons for this: The first is a simple matter of time related mathematics. Taking an average over the past 10 releases, MFD and Backlight had ~30 unique submitters per release. If even some of them managed to get themselves into habits which cost me more time than it already does to Maintain the subsystems, then either the Maintainership or my employment role would be negatively impacted. I view it better to cost each Contributor 30 mins, than it to cost me 30 mins multiplied by the amount of Contributors. Moreover, most Contributors are doing so *as part* of their employment role, where-as myself and a great many other Maintainers are operating *as well as*, or outside of ours. Secondly, this is about Contributor training and the encouragement of good practices from the outset; patch separation, expert reviews, conflict mitigation, bisection preservation, etc etc. If we train and arm the Contributors of today, we inherently encourage the Maintainers of tomorrow. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-20 8:53 ` Daniel Vetter 2017-04-20 11:30 ` Arnd Bergmann @ 2017-04-20 19:26 ` Mark Brown 1 sibling, 0 replies; 135+ messages in thread From: Mark Brown @ 2017-04-20 19:26 UTC (permalink / raw) To: Daniel Vetter Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller [-- Attachment #1: Type: text/plain, Size: 1283 bytes --] On Thu, Apr 20, 2017 at 10:53:54AM +0200, Daniel Vetter wrote: > Related to this is that there's no single stop-shop for driver > submissions for the arm platform stuff, but it's all split up. Fairly > often that means at least one of the maintainers doesn't like your > face, is on vacation or leave, burried for other reasons, or at least > has slightly different ideas about what color the bikeshed needs to > be. That makes contributions for people who just want to get their > driver for a given platform in a pain. > For non-arm-soc ecosystem drivers things seem a lot more relaxed and > efficient and sensible. I really think this is more of a cross subsystem issue than an ARM issue - I'm seeing it come up just as much with x86 stuff these days as ARM (more so at the minute, though I think that's just a bit of learning that's going on). x86 has historically been simpler hardware with less interaction between blocks that triggers cross subsystem issues but that's becoming less and less the case for the laptops. Most of what I'm seeing these days goes pretty smoothly, and we're reasonably well decoupled for the common cases so things can make progress even if one bit does end up getting stuck. AFAICT the main issues are the normal maintainer scaling problems. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 20:26 ` Arnd Bergmann 2017-04-20 8:53 ` Daniel Vetter @ 2017-04-21 11:03 ` Alexandre Belloni 2017-04-24 13:14 ` Nicolas Ferre 1 sibling, 1 reply; 135+ messages in thread From: Alexandre Belloni @ 2017-04-21 11:03 UTC (permalink / raw) To: Arnd Bergmann Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar Hi, On 19/04/2017 at 22:26:34 +0200, Arnd Bergmann wrote: > On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > What I _would_ like to see is those top maintainers suggest > > "submaintainer" names. Particularly Davem, since he doesn't tend to > > want to come to the kernel summit, and being at the top of the list > > that's a kind of big gaping hole. I guess we haven't had all that many > > _problems_ within networking, but if we talk maintainership issues, > > it's certainly a bit odd if it's entirely lacking. We have both core > > networking and network drivers that both fall under "davem" as far as > > my pull statistics go. > > For ARM, the work also tends to be fairly spread out across many > people, with few of us being overly important. [I think that while Olof and > I had similar shares of work in pulling in patches, I ended up in one of > the top spots because I happened to send more pull requests during > the last year, and I also did quite a bit of kernel stuff outside of > arch/arm.] > > So while there is no need for having lots of ARM platform maintainers, > I would like to see some of the people that I interact with that also > work with a larger number of other maintainers: > > - One of the device tree maintainers (Rob Herring, Frank Rowand, > Mark Rutland), they inevitably deal with almost all device driver > writers at some point > > - One of the CLK subsystem maintainers (Michael Turquette, > Stephen Boyd), they also interact with a large number of > subsystem and platform maintainers, and we have had some > disagreements particularly when dealing with three subsystems > (clk, arm-soc and a device driver) in one patch series. > > - One or two ARM platform maintainers, ideally one that also > maintains another kernel subsystem. I would fit that description, although mach-at91 is so small now that we have very few issues with arm-soc. However, I have two particular points: - what to do which the many coccinelle generated patches that are sent. I find that many are not tested, don't really improve readability and are sometimes harmful. I used to apply them, I don't anymore because they sometimes take too much time to review for absolutely zero benefit. The main category is the switch to devm_ functions in old drivers that are already handling error case pretty well. - my subsystem (RTC) is pretty dependant on two bus subsystems (I2C and SPI). Sometimes, it would be good to be included in discussions that will affect many drivers instead of finding that they have to be patched after the fact. I'm mainly thinking about recent work from Javier regarding OF matching in i2c. The main drawback of including more people is probably the bikeshedding that will ensue but I feel like more coordination would have been necessary to make Javier's life a bit easier. > The platforms with the most > changes are usually sunxi (Maxime Ripard), OMAP (Tony > Lindgren), Renesas (Simon Horman), Broadcom (Florian > Fainelli), Qualcomm (Andy Gross) and Freescale (Shawn Guo). > -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-21 11:03 ` Alexandre Belloni @ 2017-04-24 13:14 ` Nicolas Ferre 0 siblings, 0 replies; 135+ messages in thread From: Nicolas Ferre @ 2017-04-24 13:14 UTC (permalink / raw) To: Alexandre Belloni, Arnd Bergmann Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, Doug Ledford, David Miller Le 21/04/2017, 13:03, Alexandre Belloni wrote: > Hi, > > On 19/04/2017 at 22:26:34 +0200, Arnd Bergmann wrote: >> On Tue, Apr 18, 2017 at 8:59 PM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >> >>> What I _would_ like to see is those top maintainers suggest >>> "submaintainer" names. Particularly Davem, since he doesn't tend to >>> want to come to the kernel summit, and being at the top of the list >>> that's a kind of big gaping hole. I guess we haven't had all that many >>> _problems_ within networking, but if we talk maintainership issues, >>> it's certainly a bit odd if it's entirely lacking. We have both core >>> networking and network drivers that both fall under "davem" as far as >>> my pull statistics go. >> >> For ARM, the work also tends to be fairly spread out across many >> people, with few of us being overly important. [I think that while Olof and >> I had similar shares of work in pulling in patches, I ended up in one of >> the top spots because I happened to send more pull requests during >> the last year, and I also did quite a bit of kernel stuff outside of >> arch/arm.] >> >> So while there is no need for having lots of ARM platform maintainers, >> I would like to see some of the people that I interact with that also >> work with a larger number of other maintainers: >> >> - One of the device tree maintainers (Rob Herring, Frank Rowand, >> Mark Rutland), they inevitably deal with almost all device driver >> writers at some point >> >> - One of the CLK subsystem maintainers (Michael Turquette, >> Stephen Boyd), they also interact with a large number of >> subsystem and platform maintainers, and we have had some >> disagreements particularly when dealing with three subsystems >> (clk, arm-soc and a device driver) in one patch series. >> >> - One or two ARM platform maintainers, ideally one that also >> maintains another kernel subsystem. > > I would fit that description, although mach-at91 is so small now that we > have very few issues with arm-soc. However, I have two particular > points: > - what to do which the many coccinelle generated patches that are sent. > I find that many are not tested, don't really improve readability and > are sometimes harmful. I used to apply them, I don't anymore because > they sometimes take too much time to review for absolutely zero benefit. > The main category is the switch to devm_ functions in old drivers that > are already handling error case pretty well. > - my subsystem (RTC) is pretty dependant on two bus subsystems (I2C and > SPI). Sometimes, it would be good to be included in discussions that > will affect many drivers instead of finding that they have to be patched > after the fact. I'm mainly thinking about recent work from Javier > regarding OF matching in i2c. The main drawback of including more people > is probably the bikeshedding that will ensue but I feel like more > coordination would have been necessary to make Javier's life a bit > easier. Alexandre, correct me if I'm wrong but you could also comment on the ways to work with several co-maintainers. You have a long experience with this way of handling an ARM platform (at91, mostly with me ;-)). Co-maintainship was established 6 years ago in at91 and I think that it can be good to discuss about the best ways to put in place this model and the best practice to make it successful. Because we usually hear about it as the panacea but I do think it also has some severe drawbacks or limitations. Don't get me wrong, I do like the work we are doing right now with at91 ;-). Best regards, -- Nicolas Ferre ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (6 preceding siblings ...) 2017-04-19 20:26 ` Arnd Bergmann @ 2017-04-19 21:05 ` Andy Lutomirski 2017-04-19 21:32 ` Linus Torvalds 2017-04-21 0:35 ` Rafael J. Wysocki 2017-09-20 14:45 ` Doug Ledford 9 siblings, 1 reply; 135+ messages in thread From: Andy Lutomirski @ 2017-04-19 21:05 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Tue, Apr 18, 2017 at 11:59 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > The kernel summit is apparently in October, and I promised last year > to at least get the ball rolling with the people *I* would like to > see. What's the nominal subject matter? I'd be happy to attend, but I only sort-of maintain anything, so, to the extent it's focused on maintenance, I can stay away (down the hallway?) for size reasons too. > - security stuff > > Luto, Kees? Hi! > > - architectures > > Pretty much covered by x86, arm, powerpc, and those architectures > should talk about who within the group would attend. Since I have a habit of stirring up arch stuff, I'd be happy to talk about arch issues if they're relevant. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 21:05 ` Andy Lutomirski @ 2017-04-19 21:32 ` Linus Torvalds 2017-05-23 17:58 ` Linus Torvalds 0 siblings, 1 reply; 135+ messages in thread From: Linus Torvalds @ 2017-04-19 21:32 UTC (permalink / raw) To: Andy Lutomirski Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar On Wed, Apr 19, 2017 at 2:05 PM, Andy Lutomirski <luto@kernel.org> wrote: > On Tue, Apr 18, 2017 at 11:59 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> The kernel summit is apparently in October, and I promised last year >> to at least get the ball rolling with the people *I* would like to >> see. > > What's the nominal subject matter? I'd be happy to attend, but I only > sort-of maintain anything, so, to the extent it's focused on > maintenance, I can stay away (down the hallway?) for size reasons too. I think the nominal subject matter is "any process issue". We used to have all these specific technical issues, and talk about particular subsystems etc. That is *not* what this would be about, and would be outside the scope of the maintainer thing. People probably still want to have hallway discussions about things like that, of course, and maybe the kernel summit ends up being a good time to catch the right people, but it wouldn't be the maintainer summit part. But anything that has to not so much with any _particular_ part of the kernel, and is rather about some process issue, would be up for grabs. So questions would be around things like code organization changes or anything that cuts across subsystems and might want some hook into the process. IOW, things like security disclosure rules, test coverage, random infrastructure issues, pointing at portions of the kernel that have spotty or no maintainership, things like that. Is there something that could be automated better and we could ask the infrastructure people (whether k.org or test robot or whatever) for? Or going the other way, is there something the infrastructure people would like us to do so that they'd be able to do more? Or our interaction (or lack there-of) with the distro people? So anything like that - but not subsystem specific discussion about how to solve some problem (those would be better done at mini-summits for that subsystem, which obviously might be co-located). I *think* we agreed last year to try to limit things to just half a day, and a small enough group that we won't be running out of oxygen in the room. I think that if we have 30 people and everybody has some particular process gripe in mind that they think they could talk about for five minutes, we'll easily be able to fill half a day. The corollary to that is that if you don't have a process issue in mind, and don't expect others to be griping about you, maybe you don't want to be there. Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-19 21:32 ` Linus Torvalds @ 2017-05-23 17:58 ` Linus Torvalds 2017-05-23 18:17 ` Randy Dunlap ` (3 more replies) 0 siblings, 4 replies; 135+ messages in thread From: Linus Torvalds @ 2017-05-23 17:58 UTC (permalink / raw) To: ksummit; +Cc: David Miller Ok, I'm re-starting this thread because it's been about a month of quiet and nothing has really changed. James asked me to do another email (but during the merge window, so I was busy) and today Thorsten Leemhuis emailed about regression tracking issues, which just reminded me to get this going again. Removed everybody from the cc list except for David, because I still want him to give an alternate for the networking subsystem (unless, wonder of wonders, you're planning to be in Prague in October, David?). But the basic list that _I_ would like to see hasn't changed. That doesn't mean that this should be "The List", but I think it's just time to pass it over the wall to Ted?James?whoever is working on the non-maintainer parts of the Kernel Summit. One open question mark that James mentioned is just he vendor people - particularly if they end up being KS sponsors. I have actually traditionally liked the talks from vendors when they talk about their issues (as long as they were actual technical talks, not the marketing stuff - that's been a disaster), but I know some people found them annoying. But I think that is partly organizational and ends up involving Angela etc. We've always had sponsor people at the KS, I would not mind if they ended up having double roles as sponsor people with actual maintainer issues that they'd like to bring up. Anyway, the top-ten maintainers haven't changed, and this just reflects the "Dave Airlie suggests Daniel Vetter as a replacement". Davem, your name remains on that list because you didn't suggest alternatives.. David Miller networking and network drivers Greg KH stable and misc drivers Daniel Vetter drm (Dave Airlie) Ingo Molnar x86 and core Mauro Carvalho Chehab media drivers Arnd Bergmann arm and misc arch support Andrew Morton misc core Michael Ellerman powerpc Takashi Iwai sound (and SuSE) Doug Ledford rdma and I think any of those except probably Greg can suggest alternatives. On top of those, I had me, stable and linux-next: Linus Torvalds Ben Hutchings stable, suggested by Greg Stephen Rothwell linux-next and that's kind of the "core maintainer" list. The rest of the names are more tentative, in the sense that they are suggestions for the kinds of areas that aren't directly touched by the above. Like: - the TAB people and KS people themselves. You know who you are, and you're probably already on this list. I think there's a fair amount of overlap with this group and the developers, but it might be worth looking exactly for those kinds of "overlap" people. - Infrastructure: Konstantin Ryabitsev k.org Fengguang Wu kernel test robot Steven Rostedt ktest Shuah Khan tools/testing Thorsten Leemhuis regression tracking Jonathan Corbet documentaion .. and syzcaller/KASAN people? - Security: Andy Lutomirski security and core Kees Cook security James Morris security subsystem - Distro people: Laura Abbott Fedora Jiri Kosina (MM? JM?) Suse Rom Lemarchand Android - Filesystems? Al Viro vfs process Darrick Wong xfs Ted Ts'o ext4 - Block layer: Christoph Hellwig also rdma and taste James Bottomley Jens Axboe and I suspect picking people from these "misc" groups is at least partly about the *other* days and who is in Prague anyway.. And again, there's the whole vendor/sponsor thing, ie facebook, google, hw vendors etc. I tried to gather up names as they flew past when I thought they fit the maintainership agenda, but I was also trying to keep this particular list fairly minimal. I suspect we'll see Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-05-23 17:58 ` Linus Torvalds @ 2017-05-23 18:17 ` Randy Dunlap 2017-05-23 18:47 ` Thomas Gleixner ` (2 subsequent siblings) 3 siblings, 0 replies; 135+ messages in thread From: Randy Dunlap @ 2017-05-23 18:17 UTC (permalink / raw) To: Linus Torvalds, ksummit; +Cc: David Miller On 05/23/17 10:58, Linus Torvalds wrote: > > One open question mark that James mentioned is just he vendor people - > particularly if they end up being KS sponsors. I have actually > traditionally liked the talks from vendors when they talk about their > issues (as long as they were actual technical talks, not the marketing > stuff - that's been a disaster), but I know some people found them > annoying. But I think that is partly organizational and ends up > involving Angela etc. We've always had sponsor people at the KS, I > would not mind if they ended up having double roles as sponsor people > with actual maintainer issues that they'd like to bring up. > I think that the distros are important, but sponsors are largely either distros or huge (yuge) users, so they are also important (technical, not marketing). > Anyway, the top-ten maintainers haven't changed, and this just > reflects the "Dave Airlie suggests Daniel Vetter as a replacement". > Davem, your name remains on that list because you didn't suggest > alternatives.. > > David Miller networking and network drivers > Greg KH stable and misc drivers + usb and staging > Daniel Vetter drm (Dave Airlie) > Ingo Molnar x86 and core > Mauro Carvalho Chehab media drivers > Arnd Bergmann arm and misc arch support > Andrew Morton misc core plus MM; need more MM? > Michael Ellerman powerpc > Takashi Iwai sound (and SuSE) > Doug Ledford rdma > > and I think any of those except probably Greg can suggest alternatives. > > On top of those, I had me, stable and linux-next: > > Linus Torvalds > Ben Hutchings stable, suggested by Greg > Stephen Rothwell linux-next > > and that's kind of the "core maintainer" list. The rest of the names > are more tentative, in the sense that they are suggestions for the > kinds of areas that aren't directly touched by the above. Like: > > - the TAB people and KS people themselves. You know who you are, and > you're probably already on this list. > > I think there's a fair amount of overlap with this group and the > developers, but it might be worth looking exactly for those kinds of > "overlap" people. > > - Infrastructure: > > Konstantin Ryabitsev k.org > Fengguang Wu kernel test robot > Steven Rostedt ktest > Shuah Khan tools/testing > Thorsten Leemhuis regression tracking > Jonathan Corbet documentaion > .. and syzcaller/KASAN people? > > - Security: > > Andy Lutomirski security and core > Kees Cook security > James Morris security subsystem > > - Distro people: > > Laura Abbott Fedora > Jiri Kosina (MM? JM?) Suse > Rom Lemarchand Android > > - Filesystems? > > Al Viro vfs process > Darrick Wong xfs > Ted Ts'o ext4 > > - Block layer: > > Christoph Hellwig also rdma and taste :) > James Bottomley > Jens Axboe I would probably add some power management rep. Otherwise it looks about right to me as an observer. -- ~Randy ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-05-23 17:58 ` Linus Torvalds 2017-05-23 18:17 ` Randy Dunlap @ 2017-05-23 18:47 ` Thomas Gleixner 2017-05-23 20:34 ` Linus Torvalds 2017-05-23 19:29 ` James Bottomley 2017-05-24 3:34 ` David Miller 3 siblings, 1 reply; 135+ messages in thread From: Thomas Gleixner @ 2017-05-23 18:47 UTC (permalink / raw) To: Linus Torvalds; +Cc: David Miller, ksummit On Tue, 23 May 2017, Linus Torvalds wrote: > I tried to gather up names as they flew past when I thought they fit > the maintainership agenda, but I was also trying to keep this > particular list fairly minimal. I suspect we'll see I'm probably late, but I would like to add myself to that list. As RT (and upstream) maintainer I'm pretty involved in large scale overhauls and restructuring which is often enough a process issue. Thanks, Thomas ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-05-23 18:47 ` Thomas Gleixner @ 2017-05-23 20:34 ` Linus Torvalds 0 siblings, 0 replies; 135+ messages in thread From: Linus Torvalds @ 2017-05-23 20:34 UTC (permalink / raw) To: Thomas Gleixner, James Bottomley; +Cc: David Miller, ksummit On Tue, May 23, 2017 at 11:47 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > I'm probably late, but I would like to add myself to that list. As RT (and > upstream) maintainer I'm pretty involved in large scale overhauls and > restructuring which is often enough a process issue. So I certainly have no objection, but I think we should strive to have something approaching a "process" for the picking. I assume there's an actual official KS organizing committee, although I have no idea who would be on it, except for the presumed usual suspects (ie Ted and James). And I would suggest that in order to make it easier on them, _and_ to actually also have an agenda in place when we show up in October, people who want to nominate themselves (or somebody else, for that matter), actually write a little blurb about what they want to bring up for the agenda. That would help both the selection committee and the agenda. In the "what to bring up" blurb, I'd really suggest not just bringing up a problem, but mentioning a possible real constructive (perhaps partial) solution too, as part of why that particular person should be at the KS and why it's worth discussing. We don't want it to be a "this is a problem I have" kvetching session. We know part of the agenda already, it was discussed earlier in the thread. We've had the eternal issue about non-responsive maintainers and how to try to improve that (whether it's group maintainership or "fall-through-the-cracks" people or whatever). And I think we've discussed regression tracking pretty much every year too. But wouldn't it be good if the KS committee could basically get both a suggested agenda item and a person selection hint at the same time? Would there be some convenient way to submit those? We're all email people, so perhaps just an email with something to easily search for in the subject line. Just to the list, or who are the actual KS point men? On Tue, May 23, 2017 at 12:29 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > I'm happy to try to wrangle interesting and highly technical vendor > talks. I believe the current time plan for the maintainer summit is > half a day (is this correct?), so I propose we do vendor talks in the > other half of the day. That way people who aren't interested can take > the afternoon or morning (depending where people want it in the > timetable) off to see Prague. Sounds reasonable by me. Assuming we can get _good_ vendor talks. Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-05-23 17:58 ` Linus Torvalds 2017-05-23 18:17 ` Randy Dunlap 2017-05-23 18:47 ` Thomas Gleixner @ 2017-05-23 19:29 ` James Bottomley 2017-05-24 3:34 ` David Miller 3 siblings, 0 replies; 135+ messages in thread From: James Bottomley @ 2017-05-23 19:29 UTC (permalink / raw) To: Linus Torvalds, ksummit; +Cc: David Miller On Tue, 2017-05-23 at 10:58 -0700, Linus Torvalds wrote: > One open question mark that James mentioned is just he vendor people > - particularly if they end up being KS sponsors. I have actually > traditionally liked the talks from vendors when they talk about their > issues (as long as they were actual technical talks, not the > marketing stuff - that's been a disaster), but I know some people > found them annoying. But I think that is partly organizational and > ends up involving Angela etc. We've always had sponsor people at the > KS, I would not mind if they ended up having double roles as sponsor > people with actual maintainer issues that they'd like to bring up. I'm happy to try to wrangle interesting and highly technical vendor talks. I believe the current time plan for the maintainer summit is half a day (is this correct?), so I propose we do vendor talks in the other half of the day. That way people who aren't interested can take the afternoon or morning (depending where people want it in the timetable) off to see Prague. James ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-05-23 17:58 ` Linus Torvalds ` (2 preceding siblings ...) 2017-05-23 19:29 ` James Bottomley @ 2017-05-24 3:34 ` David Miller 2017-05-24 4:55 ` Linus Torvalds 3 siblings, 1 reply; 135+ messages in thread From: David Miller @ 2017-05-24 3:34 UTC (permalink / raw) To: torvalds; +Cc: ksummit-discuss From: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue, 23 May 2017 10:58:36 -0700 > Removed everybody from the cc list except for David, because I still > want him to give an alternate for the networking subsystem (unless, > wonder of wonders, you're planning to be in Prague in October, > David?). I'm still looking into whether I can be in Prague in October. My schedule is really tight as we are having netconf/netdev in early November in Seoul, South Korea. Unfortunately, I cannot currently recommend anyone seriously as an alternate to represent networking. I know that's not the answer you want to hear, but I'll keep thinking about this. The last time I left the networking tree in someone else's hands for even just a few days was about a decade ago and that person's focus is significantly different these days. Thanks. ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-05-24 3:34 ` David Miller @ 2017-05-24 4:55 ` Linus Torvalds 0 siblings, 0 replies; 135+ messages in thread From: Linus Torvalds @ 2017-05-24 4:55 UTC (permalink / raw) To: David Miller; +Cc: ksummit On Tue, May 23, 2017 at 8:34 PM, David Miller <davem@davemloft.net> wrote: > > I'm still looking into whether I can be in Prague in October. > > My schedule is really tight as we are having netconf/netdev > in early November in Seoul, South Korea. Ok. Which I assume means that all the other networking people will be in the same situation. But maybe there is somebody who is at least close to you from a workflow and maintainership angle, and where Prague is more convenient despite netconf/netdev? Looking at your merges, you seem to merge mostly from Jef Kirsher, Johannes Berg or Pablo Neira Ayuso. Although that was from some very rough git scripting that that might be debatable: git rev-list --merges --author=davem --since=12.months HEAD | while read i; do git log -1 --pretty='%cn' $i^2; done | sort | uniq -c | sort -n although looking at that, it really doesn't look like core networking. Another way to show networking maintainership stats: git shortlog -csn --since=12.months net/ and yeah, you clearly do seem to work mostly with patches rather than submaintainers., backing up that "davem's merge sources aren't very interesting" > Unfortunately, I cannot currently recommend anyone seriously as an > alternate to represent networking. I know that's not the answer you > want to hear, but I'll keep thinking about this. > > The last time I left the networking tree in someone else's hands > for even just a few days was about a decade ago and that person's > focus is significantly different these days. Heh. Maybe we should have a maintainership discussion about "What if davem is hit by a bus?" ;) Linus ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (7 preceding siblings ...) 2017-04-19 21:05 ` Andy Lutomirski @ 2017-04-21 0:35 ` Rafael J. Wysocki 2017-09-20 14:45 ` Doug Ledford 9 siblings, 0 replies; 135+ messages in thread From: Rafael J. Wysocki @ 2017-04-21 0:35 UTC (permalink / raw) To: Linus Torvalds Cc: ksummit-discuss, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar Hi Linus, On Tuesday, April 18, 2017 11:59:37 AM Linus Torvalds wrote: > The kernel summit is apparently in October, and I promised last year > to at least get the ball rolling with the people *I* would like to > see. [cut] > So the other way to split it up is by "maintenance area", ie we have > > - architectures > > Pretty much covered by x86, arm, powerpc, and those architectures > should talk about who within the group would attend. > > - drivers > > Obviously we have Greg overall, with drm and rdma because of issues. > > An example here is that Christoph doesn't show up because I don't > generally pull from him, but he's been all over and often crosses > multiple driver subsystems, and has been involved in rdma too, so I'd > add him just for that. > > Some driver subsystems may be huge (eg media and sound), but I > don't know if they have issues. Mauro/Takashi? > > - filesystems > > Al, XSF and ext4 stand out by size (XFS is mostly Dave Chinner due > to me going by past year, but is obviously Darrick Wong right now). > > - core stuff. > > We've got Andrew, and I'd add Tejun from the list, with others > possible? Maintenance issues here are actually sometimes contentious > even if the core kernel is fairly small. > > - security stuff > > Luto, Kees? > > - particular pain points. Any not mentioned? > > - other? I'm not sure if PM can be regarded as "core stuff" or "drivers", but it just tends to be spread all over, so I guess it's sort of unusual. It interacts with pretty much everything, though, so maybe should be represented? ;-) Also I have a couple of pain points, although to be entirely honest I don't really think about them on a daily basis, so you can count me as relatively happy in that respect. :-) But since you are asking, one thing that bothers me is that I seem to be the only person on the planet sufficiently familiar with some pieces of kernel code to be able to fix issues in them without an extensive research. At least nobody else openly admits to be familiar with that code too. I guess the reason why is that I tend to take care of code rarely looked at by anyone else and people look at it mostly if it causes problems visible to them to happen this way or another. Then, once the problem at hand goes away, they go back to the other stuff which presumably is more interesting to them. I often end up fixing those issues myself, just because I'm familiar with the code in question, and so this goes on. That's not a particularly comfortable situation to be in for various reasons, but I have to admit that I don't really know how to address it generally and long-term. It would boil down to finding somebody who would be sufficiently interested in that code to understand all of it and would stay on the project for long enough, but that's sort of hard. [Besides, there are pieces of kernel code familiar to no one with a valid e-mail address (like some cpufreq drivers for an easy example) and there is barely any hardware they can be tested on after modifications (which sometimes are necessary due to framework changes etc).] It also is hard to make people review code changes in a meaningful way, especially if the code being modified is not what they work on routinely. That's entirely understandable to me, because if that's not part of their job, it becomes tedious unpaid work done voluntarily for the better good of everyone, so to speak, and totally unrewarding in many cases. That is not to say that code review doesn't happen. It happens, but not as much as to make me entirely happy. At the same time I don't really think it would be good to make code review mandatory overall. In fact, I'm not sure if doing that would improve things at all. I wonder, however, if it is possible to make code review generally more rewarding (or attractive?) somehow. Finally, there is quite a bit of code in various vendor or product trees and similar that's never submitted to us and we don't even know about it, but it is shipped in products. Also, there are drivers available as source code that can be downloaded from vendor web sites, but are never submitted for merging. This clearly means to me that there's not enough incentive for people to submit their code and I wonder if there's anything we can do to address that. Moreover, I actually would prefer problems or use cases to be discussed with us before any code is implemented, but quite evidently there's no incentive for that either. > I'd like the maintainership summit list to be fairly small. Not even > 50 people. Maybe 30. A group that can actually sit in a room for half > a day and talk to each other about the issues they have rather than > being talked to. And talk literally about *process* issues, not about > any particular technical issues within whatever subsystem. Bring up > peeves or wishes for actual process improvements? > > Comments? People who should be involved? Or people who don't have any > particular issues and want to not be involved? As for who should be involved, IMO if that's going to be a "maintainer summit", the majority of people in the room should be maintainers. I would go for proportions like 2/3 maintainers and 1/3 distro/infrastructure/testing/users/etc with the total number somewhere between 36 and 45. Cheers, Rafael ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds ` (8 preceding siblings ...) 2017-04-21 0:35 ` Rafael J. Wysocki @ 2017-09-20 14:45 ` Doug Ledford 2017-09-20 15:07 ` James Bottomley 9 siblings, 1 reply; 135+ messages in thread From: Doug Ledford @ 2017-09-20 14:45 UTC (permalink / raw) To: Linus Torvalds, ksummit Cc: Ingo Molnar, Dave Airlie, Greg Kroah-Hartman, David Miller [-- Attachment #1.1: Type: text/plain, Size: 990 bytes --] On 4/18/2017 2:59 PM, Linus Torvalds wrote: > I'd like the maintainership summit list to be fairly small. Not even > 50 people. Maybe 30. A group that can actually sit in a room for half > a day and talk to each other about the issues they have rather than > being talked to. And talk literally about *process* issues, not about > any particular technical issues within whatever subsystem. Bring up > peeves or wishes for actual process improvements? > > Comments? People who should be involved? Or people who don't have any > particular issues and want to not be involved? Hi Linus, Do we have a final determination as to whether or not this is going to happen? I got the impression from this thread that it was "tentative" and not certain. If it's going to happen, I should probably get my travel request in. -- Doug Ledford <dledford@redhat.com> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 14:45 ` Doug Ledford @ 2017-09-20 15:07 ` James Bottomley 2017-09-20 15:22 ` Doug Ledford 2017-09-21 4:54 ` James Morris 0 siblings, 2 replies; 135+ messages in thread From: James Bottomley @ 2017-09-20 15:07 UTC (permalink / raw) To: Doug Ledford, Linus Torvalds, ksummit Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, David Miller [-- Attachment #1: Type: text/plain, Size: 1359 bytes --] On Wed, 2017-09-20 at 10:45 -0400, Doug Ledford wrote: > On 4/18/2017 2:59 PM, Linus Torvalds wrote: > > > > > I'd like the maintainership summit list to be fairly small. Not > > even 50 people. Maybe 30. A group that can actually sit in a room > > for half a day and talk to each other about the issues they have > > rather than being talked to. And talk literally about *process* > > issues, not about any particular technical issues within whatever > > subsystem. Bring up peeves or wishes for actual process > > improvements? > > > > Comments? People who should be involved? Or people who don't have > > any particular issues and want to not be involved? > > Hi Linus, > > Do we have a final determination as to whether or not this is going > to happen? I got the impression from this thread that it was > "tentative" and not certain. If it's going to happen, I should > probably get my travel request in. We've collected the sponsor's money and paid for the space, so it's as certain to happen as any previous kernel summit. The maintainer's summit is tacked on to a bigger kernel summit, which is open to all and also has reserved space in Prague. You just register for the Open Source Summit Europe to come to that one: http://events.linuxfoundation.org/events/linux-kernel-summit/attend/register James [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 15:07 ` James Bottomley @ 2017-09-20 15:22 ` Doug Ledford 2017-09-20 15:31 ` James Bottomley 2017-09-21 4:54 ` James Morris 1 sibling, 1 reply; 135+ messages in thread From: Doug Ledford @ 2017-09-20 15:22 UTC (permalink / raw) To: James Bottomley, Linus Torvalds, ksummit Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, David Miller [-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --] On 9/20/2017 11:07 AM, James Bottomley wrote: > On Wed, 2017-09-20 at 10:45 -0400, Doug Ledford wrote: >> On 4/18/2017 2:59 PM, Linus Torvalds wrote: >> >>> >>> I'd like the maintainership summit list to be fairly small. Not >>> even 50 people. Maybe 30. A group that can actually sit in a room >>> for half a day and talk to each other about the issues they have >>> rather than being talked to. And talk literally about *process* >>> issues, not about any particular technical issues within whatever >>> subsystem. Bring up peeves or wishes for actual process >>> improvements? >>> >>> Comments? People who should be involved? Or people who don't have >>> any particular issues and want to not be involved? >> >> Hi Linus, >> >> Do we have a final determination as to whether or not this is going >> to happen? I got the impression from this thread that it was >> "tentative" and not certain. If it's going to happen, I should >> probably get my travel request in. > > We've collected the sponsor's money and paid for the space, so it's as > certain to happen as any previous kernel summit. I knew the kernel summit was going to happen... > The maintainer's > summit is tacked on to a bigger kernel summit, which is open to all and > also has reserved space in Prague. The question is whether or not this is going to happen... > You just register for the Open > Source Summit Europe to come to that one: > > http://events.linuxfoundation.org/events/linux-kernel-summit/attend/register > > James > -- Doug Ledford <dledford@redhat.com> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 15:22 ` Doug Ledford @ 2017-09-20 15:31 ` James Bottomley 2017-09-20 15:58 ` Doug Ledford 0 siblings, 1 reply; 135+ messages in thread From: James Bottomley @ 2017-09-20 15:31 UTC (permalink / raw) To: Doug Ledford, Linus Torvalds, ksummit Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, David Miller [-- Attachment #1: Type: text/plain, Size: 1839 bytes --] On Wed, 2017-09-20 at 11:22 -0400, Doug Ledford wrote: > On 9/20/2017 11:07 AM, James Bottomley wrote: > > > > On Wed, 2017-09-20 at 10:45 -0400, Doug Ledford wrote: > > > > > > On 4/18/2017 2:59 PM, Linus Torvalds wrote: > > > > > > > > > > > > > > > I'd like the maintainership summit list to be fairly small. Not > > > > even 50 people. Maybe 30. A group that can actually sit in a > > > > room for half a day and talk to each other about the issues > > > > they have rather than being talked to. And talk literally about > > > > *process* issues, not about any particular technical issues > > > > within whatever subsystem. Bring up peeves or wishes for actual > > > > process improvements? > > > > > > > > Comments? People who should be involved? Or people who don't > > > > have any particular issues and want to not be involved? > > > > > > Hi Linus, > > > > > > Do we have a final determination as to whether or not this is > > > going to happen? I got the impression from this thread that it > > > was "tentative" and not certain. If it's going to happen, I > > > should probably get my travel request in. > > > > We've collected the sponsor's money and paid for the space, so it's > > as certain to happen as any previous kernel summit. > > I knew the kernel summit was going to happen... I took "this" in your email to refer to Maintainer Summit, so that's what the above is about. > > The maintainer's summit is tacked on to a bigger kernel summit, > > which is open to all and also has reserved space in Prague. > > The question is whether or not this is going to happen... Confused by what "this" is here, however: both the kernel summit and the maintainer summit are happening. The former merely requires a OSSE+ELCE pass and the latter an invite. James [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 15:31 ` James Bottomley @ 2017-09-20 15:58 ` Doug Ledford 2017-09-20 22:55 ` Theodore Ts'o 0 siblings, 1 reply; 135+ messages in thread From: Doug Ledford @ 2017-09-20 15:58 UTC (permalink / raw) To: James Bottomley, Linus Torvalds, ksummit Cc: Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, David Miller [-- Attachment #1.1: Type: text/plain, Size: 1698 bytes --] On 9/20/2017 11:31 AM, James Bottomley wrote: > On Wed, 2017-09-20 at 11:22 -0400, Doug Ledford wrote: >> On 9/20/2017 11:07 AM, James Bottomley wrote: >>>> Do we have a final determination as to whether or not this is >>>> going to happen? I got the impression from this thread that it >>>> was "tentative" and not certain. If it's going to happen, I >>>> should probably get my travel request in. >>> >>> We've collected the sponsor's money and paid for the space, so it's >>> as certain to happen as any previous kernel summit. >> >> I knew the kernel summit was going to happen... > > I took "this" in your email to refer to Maintainer Summit, so that's > what the above is about. Ah, see, while I was on this thread and named by Linus as one of the subsystems that he sees might benefit from this, I never got an invite so I didn't know the maintainer summit was happening versus tentative. >>> The maintainer's summit is tacked on to a bigger kernel summit, >>> which is open to all and also has reserved space in Prague. >> >> The question is whether or not this is going to happen... > > Confused by what "this" is here, I was referring to the maintainer's summit. The kernel summit was a given, and I thought you were referring to it when you said it was booked and paid for. > however: both the kernel summit and > the maintainer summit are happening. The former merely requires a > OSSE+ELCE pass and the latter an invite. See above as to why I didn't know if it was happening. -- Doug Ledford <dledford@redhat.com> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 15:58 ` Doug Ledford @ 2017-09-20 22:55 ` Theodore Ts'o 2017-09-21 9:33 ` Leon Romanovsky 0 siblings, 1 reply; 135+ messages in thread From: Theodore Ts'o @ 2017-09-20 22:55 UTC (permalink / raw) To: Doug Ledford Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, James Bottomley, Ingo Molnar On Wed, Sep 20, 2017 at 11:58:28AM -0400, Doug Ledford wrote: > Ah, see, while I was on this thread and named by Linus as one of the > subsystems that he sees might benefit from this, I never got an invite > so I didn't know the maintainer summit was happening versus tentative. Linus sent a list of names to the program committee, and with a list a core people he definitely wanted there, and set of other names, and asked the program committee to make the final selection, using criteria that he gave us. Invites have gone out, and I'll post a draft agenda and confirmed attendees shortly --- a few people who did receive invites (including James, cough, cough) haven't RSVP'ed yet. I'll send nag mails out as well. Cheers, - Ted ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 22:55 ` Theodore Ts'o @ 2017-09-21 9:33 ` Leon Romanovsky 0 siblings, 0 replies; 135+ messages in thread From: Leon Romanovsky @ 2017-09-21 9:33 UTC (permalink / raw) To: Theodore Ts'o Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, Ingo Molnar, James Bottomley, Doug Ledford, David Miller [-- Attachment #1: Type: text/plain, Size: 1091 bytes --] On Wed, Sep 20, 2017 at 06:55:34PM -0400, Theodore Ts'o wrote: > On Wed, Sep 20, 2017 at 11:58:28AM -0400, Doug Ledford wrote: > > Ah, see, while I was on this thread and named by Linus as one of the > > subsystems that he sees might benefit from this, I never got an invite > > so I didn't know the maintainer summit was happening versus tentative. > > Linus sent a list of names to the program committee, and with a list a > core people he definitely wanted there, and set of other names, and > asked the program committee to make the final selection, using > criteria that he gave us. > > Invites have gone out, and I'll post a draft agenda and confirmed > attendees shortly --- a few people who did receive invites (including > James, cough, cough) haven't RSVP'ed yet. I'll send nag mails out as > well. Is it possible to share this final list publicly? Thanks > > Cheers, > > - Ted > _______________________________________________ > 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: 833 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Ksummit-discuss] "Maintainer summit" invitation discussion 2017-09-20 15:07 ` James Bottomley 2017-09-20 15:22 ` Doug Ledford @ 2017-09-21 4:54 ` James Morris 1 sibling, 0 replies; 135+ messages in thread From: James Morris @ 2017-09-21 4:54 UTC (permalink / raw) To: James Bottomley Cc: ksummit, Dave Airlie, Greg Kroah-Hartman, David Miller, Doug Ledford, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 681 bytes --] On Wed, 20 Sep 2017, James Bottomley wrote: > We've collected the sponsor's money and paid for the space, so it's as > certain to happen as any previous kernel summit. The maintainer's > summit is tacked on to a bigger kernel summit, which is open to all and > also has reserved space in Prague. You just register for the Open > Source Summit Europe to come to that one: > > http://events.linuxfoundation.org/events/linux-kernel-summit/attend/register Is there any information available on the format of the open kernel summit? I couldn't find anything on the event web site except a mention of a kernel summit track at OSS Europe. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 135+ messages in thread
end of thread, other threads:[~2017-09-21 9:33 UTC | newest] Thread overview: 135+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-18 18:59 [Ksummit-discuss] "Maintainer summit" invitation discussion Linus Torvalds 2017-04-18 19:50 ` Takashi Iwai 2017-04-18 20:13 ` Linus Torvalds 2017-04-18 20:21 ` Jiri Kosina 2017-04-18 20:36 ` Takashi Iwai 2017-04-18 20:29 ` Takashi Iwai 2017-04-18 20:33 ` Laura Abbott 2017-04-18 21:15 ` Mauro Carvalho Chehab 2017-04-19 22:36 ` Jonathan Corbet 2017-04-19 22:41 ` Jiri Kosina 2017-04-19 23:36 ` Josh Triplett 2017-04-19 23:51 ` Jiri Kosina 2017-04-20 1:04 ` Josh Triplett 2017-04-20 7:38 ` Jani Nikula 2017-04-20 5:23 ` Christoph Hellwig 2017-04-20 13:33 ` James Bottomley 2017-04-20 14:40 ` Alexey Dobriyan 2017-04-20 14:52 ` Ingo Molnar 2017-04-20 14:47 ` Jonathan Corbet 2017-04-20 15:34 ` James Bottomley 2017-04-20 11:25 ` Mauro Carvalho Chehab 2017-04-19 15:37 ` Doug Ledford 2017-04-19 16:18 ` Linus Torvalds 2017-04-19 16:24 ` Doug Ledford 2017-04-19 18:11 ` Justin Forbes 2017-04-19 21:52 ` Geert Uytterhoeven 2017-04-19 18:21 ` Laura Abbott 2017-04-20 8:31 ` Jani Nikula 2017-04-20 12:35 ` Mark Brown 2017-04-20 13:01 ` Jani Nikula 2017-04-21 8:41 ` Alexandre Belloni 2017-04-21 14:46 ` David Miller 2017-04-20 8:17 ` Jani Nikula 2017-04-20 10:59 ` Greg Kroah-Hartman 2017-04-20 12:22 ` Jani Nikula 2017-04-20 13:03 ` Greg Kroah-Hartman 2017-04-20 14:49 ` Mark Brown 2017-04-19 19:25 ` Laurent Pinchart 2017-04-19 19:40 ` Linus Torvalds 2017-04-19 19:45 ` Jens Axboe 2017-04-19 19:50 ` Laurent Pinchart 2017-04-19 19:55 ` James Bottomley 2017-04-20 8:26 ` Daniel Vetter 2017-04-20 13:25 ` James Bottomley 2017-04-25 16:02 ` Bart Van Assche 2017-04-25 16:38 ` Guenter Roeck 2017-04-25 16:56 ` Mark Brown 2017-04-26 3:47 ` Bart Van Assche 2017-04-26 8:39 ` Geert Uytterhoeven 2017-04-26 14:21 ` Mark Brown 2017-04-26 14:51 ` David Miller 2017-04-26 15:15 ` Mark Brown 2017-04-26 8:42 ` Dan Carpenter 2017-04-26 13:58 ` Martin K. Petersen 2017-04-26 14:15 ` Andrew Lunn 2017-04-26 15:42 ` Martin K. Petersen 2017-04-26 14:31 ` James Bottomley 2017-04-26 14:34 ` Jiri Kosina 2017-04-26 14:43 ` James Bottomley 2017-04-27 9:06 ` Jani Nikula 2017-04-27 10:41 ` Lee Jones 2017-04-27 11:02 ` Hannes Reinecke 2017-04-27 14:17 ` James Bottomley 2017-04-28 0:24 ` Rafael J. Wysocki 2017-04-27 15:40 ` Wolfram Sang 2017-04-26 15:02 ` Bart Van Assche 2017-04-26 15:25 ` James Bottomley 2017-04-26 15:36 ` Mark Brown 2017-04-19 20:14 ` Josh Triplett 2017-04-19 21:30 ` Laurent Pinchart 2017-04-20 5:44 ` Julia Lawall 2017-04-20 8:54 ` Laurent Pinchart 2017-04-19 19:58 ` Konstantin Ryabitsev 2017-04-19 20:20 ` Jiri Kosina 2017-04-18 20:00 ` Dave Airlie 2017-04-18 20:29 ` Laurent Pinchart 2017-04-18 20:38 ` Daniel Vetter 2017-04-18 20:56 ` Linus Torvalds 2017-04-18 21:39 ` Daniel Vetter 2017-04-20 19:02 ` Mark Brown 2017-04-18 20:06 ` Serge E. Hallyn 2017-04-18 20:11 ` Greg Kroah-Hartman 2017-04-18 20:21 ` Linus Torvalds 2017-04-25 15:09 ` Chris Mason 2017-04-19 0:22 ` Stephen Rothwell 2017-04-19 13:35 ` Shuah Khan 2017-04-19 20:20 ` James Bottomley 2017-04-19 20:27 ` Jiri Kosina 2017-04-20 10:24 ` Mauro Carvalho Chehab 2017-04-21 8:51 ` Alexandre Belloni 2017-04-21 8:55 ` Julia Lawall 2017-04-21 8:59 ` Wolfram Sang 2017-04-21 14:45 ` Mauro Carvalho Chehab 2017-04-21 10:34 ` Michael Ellerman 2017-04-21 15:06 ` Mauro Carvalho Chehab 2017-04-21 23:37 ` James Bottomley 2017-04-20 16:01 ` Dan Williams 2017-04-21 11:07 ` Michael Ellerman 2017-04-21 17:06 ` Mauro Carvalho Chehab 2017-04-21 23:19 ` Bjorn Helgaas 2017-04-19 20:26 ` Arnd Bergmann 2017-04-20 8:53 ` Daniel Vetter 2017-04-20 11:30 ` Arnd Bergmann 2017-04-20 13:46 ` Daniel Vetter 2017-04-24 14:02 ` Olof Johansson 2017-04-24 16:17 ` Linus Walleij 2017-04-24 17:29 ` Olof Johansson 2017-04-24 17:58 ` Mark Brown 2017-04-25 9:10 ` Lee Jones 2017-04-29 21:00 ` Daniel Vetter 2017-04-29 21:39 ` James Bottomley 2017-04-30 12:45 ` Mark Brown 2017-04-30 19:12 ` Olof Johansson 2017-05-02 8:09 ` Lee Jones 2017-04-20 19:26 ` Mark Brown 2017-04-21 11:03 ` Alexandre Belloni 2017-04-24 13:14 ` Nicolas Ferre 2017-04-19 21:05 ` Andy Lutomirski 2017-04-19 21:32 ` Linus Torvalds 2017-05-23 17:58 ` Linus Torvalds 2017-05-23 18:17 ` Randy Dunlap 2017-05-23 18:47 ` Thomas Gleixner 2017-05-23 20:34 ` Linus Torvalds 2017-05-23 19:29 ` James Bottomley 2017-05-24 3:34 ` David Miller 2017-05-24 4:55 ` Linus Torvalds 2017-04-21 0:35 ` Rafael J. Wysocki 2017-09-20 14:45 ` Doug Ledford 2017-09-20 15:07 ` James Bottomley 2017-09-20 15:22 ` Doug Ledford 2017-09-20 15:31 ` James Bottomley 2017-09-20 15:58 ` Doug Ledford 2017-09-20 22:55 ` Theodore Ts'o 2017-09-21 9:33 ` Leon Romanovsky 2017-09-21 4:54 ` James Morris
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.