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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Tue, Oct 24, 2017 at 05:54:47PM -0700, Kees Cook wrote:

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

IME if you use all matching MAINTAINERS entries rather than the most
exact one you'll usually find the upstream (though there are exceptions,
including things like arm-soc which just isn't in MAINTAINERS at all).

> 7) As seen in this topic thread, some maintainers absolutely do not
> want stuff landing from "outside" their tree. This doesn't seem
> feasible at all, and we do regular treewide conversions at -rc1. It
> would be nice to declare, explicitly, "you need to deal with external
> changes to your tree when you merge -rc1". I thought this was already
> an implicit understanding. (Though in fact, sfr suggested to me that
> maintainer trees should be based at least on -rc2, and I've seen some

I think like a lot of these things this is a tradeoffs thing - sometimes
everything will have to go in at once and we'll have to deal with it but
it's better to at least try to coordinate with people's trees, if that's
not possible it's annoying but understandable.  It's more likely to be a
problem when things just materialize without any warning.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]