From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B130BAAE for ; Wed, 25 Oct 2017 04:37:02 +0000 (UTC) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A00B214B for ; Wed, 25 Oct 2017 04:37:01 +0000 (UTC) Date: Wed, 25 Oct 2017 06:36:56 +0200 (CEST) From: Julia Lawall To: Joe Perches In-Reply-To: <1508905764.10651.10.camel@perches.com> Message-ID: References: <20171005192002.hxbjjdjhrfa4oa37@thunk.org> <1507303665.3104.13.camel@HansenPartnership.com> <1508888508.1955.16.camel@perches.com> <1508905764.10651.10.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: James Bottomley , ksummit Subject: Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 24 Oct 2017, Joe Perches wrote: > On Wed, 2017-10-25 at 06:21 +0200, Julia Lawall wrote: > > > > On Tue, 24 Oct 2017, Kees Cook wrote: > > > > > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches wrote: > > > > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: > > > > > On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley > > > > > wrote: > > > > > > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > > > > > > > Appendix: Other topics that were brought up > > > > > > > [...] > > > > > > > Developing across multiple areas of the kernel > > > > > > > > > > > > I've got a couple of extra possibilities > > > > > > [...] > > > > > > 2) Trivial patches (again). > > > > > > > > > > Given that the "trivial patches" topic's discussion ended up boiling > > > > > down to a discussion about developing across multiple areas of the > > > > > kernel, maybe we should make space for a "tree-wide changes" > > > > > discussion? Even after the earlier thread about it, I tripped all over > > > > > this in the last couple months while doing timer conversions, so I > > > > > would at least have some more strong opinions on the subject. ;) > > > > > > > > It's a ripe area (like months old limburger cheese) for discussion. > > > > > > > > There's currently no good way to do tree-wide changes. > > > > > > Some things stand out for me: > > > > > > 1) I would like a standard way to distinguish patch submissions > > > between "please ack this (it's going into my tree)" and "please apply > > > this to your tree." I have tried post-"---"-line notes, cover letter > > > notes, etc, and maintainers still miss it. It can sometimes be very > > > disruptive (to both me and the maintainer) to have a maintainer take a > > > patch out of the middle of a series that was intending to land via a > > > different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or > > > "[MY-TREE]" or something? > > > > Nothing is going into my tree, since I don't have one. > > Me too. > > > Most changes I do > > are independent, so I hope that the recipient of the patch will take it. > > And generally I will only send such a patch series once. Likewise. julia > > > I only send such patches to the maintainers of the patch, with the cover > > letter CCd to some superset of all relevant mailing lists. I don't really > > know what to do with dependent patches. Sending all patches to the union > > of all maintainers can lead to a huge CC list. In that case, I would have > > to hope that someone who step up to pick up the patch, perhaps the person > > who is maintaining the dependency part, or when someone asked for the > > change, the person whoc asked for it in the first place. > > I generally send treewide patches by second-level directory, > third if it's drivers/net/ > > > > 2) When you have a 200+ patch series, it is outrageously difficult to > > > figure out where to send things. > > More like impossible. > > > > This would allow > > > for a sane set of "Cc"s not based on git log guessing, and provide an > > > obvious "escalation" path in the face of silence (or uncommitted > > > Acks). > > More likely a treewide maintainer for the obvious/trivial but acceptable > would help more. > > > I send things to maintainers and mailing lists only. My hypothesis is > > that the things affected by treewide canges are typically not things that > > other developers feel a strong ownership of. > > Unfortunately, that's also the class of patches that no one cares much > about. > > > > 8) Whatever the results of this, I'd really like to get _something_ > > > documented as an adjunct to the SubmittingPatches document. Maybe > > > named TreewideChanges or MultiSubsystemChanges or something. I'm happy > > > to DO this documentation, I just want to have consensus on the ways to > > > do things, and then I can point maintainers to the document to explain > > > why I did something the way I did. > > > > Documentation would indeed be very helpful. > > > > Another question is how a patch series should be cut up? Some people have > > complained about it being cut up by file, if the changes are all going > > into the same tree. And of course there are complaints if files from two > > trees are mixed into a single patch. I normally cut them up by unique set > > of maintainers, but sometimes quite different files get put into a single > > patch, or files that are very similar get split between different patches > > just because there is one extra maintainer on one of them. Would it be > > better to follow the T: entry in MAINTAINERS, if there is one? That > > information doesn't seem to be complete. > > It's not and it's also incomplete when overlap of ownership occurs. > >