Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning

[Joe Perches <joe@perches.com>]

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 <joe@perches.com> wrote:
> > > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote:
> > > > On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley
> > > > <James.Bottomley@hansenpartnership.com> 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.

> 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.