lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <565bfe3cd09197903ae07a87aadd94d1117d4106.camel@perches.com>
Date:   Fri, 05 Feb 2021 06:06:57 -0800
From:   Joe Perches <joe@...ches.com>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Jonathan Corbet <corbet@....net>
Cc:     devel@...ts.elisa.tech,
        Ralf Ramsauer <ralf.ramsauer@...-regensburg.de>,
        Wolfgang Mauerer <wolfgang.mauerer@...-regensburg.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Pia Eichinger <pia.eichinger@...oth-regensburg.de>,
        Başak Erdamar <basakerdamar@...il.com>
Subject: Re: Small student project idea on appropriate integration trees in
 MAINTAINERS

On Fri, 2021-02-05 at 07:42 +0100, Lukas Bulwahn wrote:
> On Fri, Jan 29, 2021 at 12:54 AM Jonathan Corbet <corbet@....net> wrote:
> > 
> > On Fri, 22 Jan 2021 09:22:24 +0100
> > Lukas Bulwahn <lukas.bulwahn@...il.com> 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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ