Re: Small student project idea on appropriate integration trees in MAINTAINERS

[Joe Perches]

On Fri, 2021-02-05 at 07:42 +0100, Lukas Bulwahn wrote:
> On Fri, Jan 29, 2021 at 12:54 AM Jonathan Corbet <corbet@xxxxxxx> wrote:
> > 
> > On Fri, 22 Jan 2021 09:22:24 +0100
> > Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote:
> > 
> > > In this project, we can make use of:
> > > 
> > > - gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to
> > > parse MAINTAINERS and obtain the integration tree patch of a commit.
> > 
> > Look also at the 'treeplot' tool there, which determines which tree(s)
> > each patch went through and makes pretty (OK, not hugely pretty) pictures
> > from the result.
> 
> Thanks, we are well aware, and that is a good reminder for Basak and
> me to get our gitdm treeplot patches in shape for proper submission.
> 
> > 
> > I suspect you'll find that the tree information is mostly correct.
> 
> Your suspicion, which is counter to my hypothesis, makes this
> investigation worthwhile just to see how correct that information
> really is.

I suspect the specific development trees listed in each MAINTAINERS
subsystems is mostly useless information.

Just like the number of subsystems listed and their nominal maintainers
is more vanity than actual.  MAINTAINER subsystems may be active for
a small window of time when submitted, but these mostly driver entries
are quickly aged out as the typically driver is completed.

The 80:20 rule when applied to MAINTAINERS I suspect is more like 90:10.

> > Developers need to know that to be able to base their patches properly; an
> > incorrect entry would lead to a certain amount of maintainer misery.

The -next integration tree works relatively well as the basis for
development.  If a patch doesn't apply, it's typically fairly easy
to rebase it in the rare occasion it doesn't apply to a particular
active tree.