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

[Kees Cook <keescook@chromium.org>]

On Tue, Oct 31, 2017 at 12:19 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Oct 24, 2017 at 7:54 PM, Kees Cook <keescook@chromium.org> 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?
>
> I've used To vs. Cc to distinguish that, but that seems to be not
> explicit enough.

Yeah, same for me.

> Perhaps a "Needs-Acked-by:" tag. That would have the advantage of
> being stored in the commit rather than having to be added when
> sending. It's also easy for the person needing to ack it to filter for
> it. The more we can automate the process from having a git branch of
> commits to sending mails, the less variation we have and the easier it
> will be for new people.

I tend to be faced with not knowing which person I need for an Ack. :P

The idea proposed at Kernel Summit was to add a new subject tag
"Request for Ack", as:

[RFACK][PATCH] subsystem: title...

>> 2) When you have a 200+ patch series, it is outrageously difficult to
>> figure out where to send things. The MAINTAINERS file is at best an
>> approximation. I use a subset of the get_maintainer output plus my own
>> parsing of MAINTAINERS to try to organize patches. The results tend to
>> be somewhat okay, but there are still bouncing addresses, or MIA
>> maintainers. And then a patch isn't met with silence, it might get met
>> with an "Ack", but no attention from a committer. Having a
>> representation of the "tree" of maintainership would be much more
>> helpful. In other words, for every section with an "M:" line, also
>> something "U:" ("upstream"?) that indicates either another section or
>> a person that is the "upstream" for that maintainer. 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).
>
> I think distinguishing between subsystem maintainers and maintainers
> of individual things (e.g. a driver) would be good. I think that's
> what you are saying. Ideally, that distinction would make it to the Cc

Yeah, exactly. And time times (wireless comes to mind) you have a
couple levels of maintainers of the "individual thing" maintainers.

> list somehow. I usually add Cc's from get_maintainers.pl to commits,
> but then by the time I'm sending things I may not know who in the list
> has the upstream tree.
>
> The git log guessing is pretty useless for the purpose of Cc'ing
> people and should be off by default IMO. I've touched things tree wide
> a number of times and now get Cc'ed on things I've touched once 3
> years ago.

Yeah, I fear my inbox after timer conversions start landing...

-Kees

-- 
Kees Cook
Pixel Security