linux-kernel - Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <23317635-426e-fbf8-f0b2-b59dde75900a@denx.de>
Date:   Tue, 18 Oct 2016 21:31:06 +0200
From:   Marek Vasut <marex@...x.de>
To:     Brian Norris <computersforpeace@...il.com>,
        Richard Weinberger <richard@....at>
Cc:     Cyrille Pitchen <cyrille.pitchen@...el.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        nicolas.ferre@...el.com,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        LKML <linux-kernel@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Artem Bityutskiy <dedekind1@...il.com>
Subject: Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR
 subsystem

On 10/18/2016 08:46 PM, Brian Norris wrote:

[...]

>>>>>> Boris Brezillon has already stepped up as a maintainer for the NAND
>>>>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in
>>>>>> the same way: I would be reviewing patches touching this area, collecting
>>>>>> them and sending pull requests to Brian Norris.
>>>>
>>>> I'd suggest you send pull requests directly to Linus.
>>>> Same for NAND.
> 
> I could go with either method I suppose, but I don't personally like the
> idea of splitting out the various bits of MTD into *completely*
> independent lines of development. As long as someone (not necessarily
> me) can manage pulling the sub-subsystems together, I think it would
> make sense to have 1 PR for Linus for non-UBI/FS MTD changes.

Yes please, agreed. This looks far more systematic and it's what other
subsystems do.

[...]

> Random thoughts:

[...]

>  Coordination: how do we avoid stepping on each other's toes? We'd have
>  to definitely 100% kill 'git push -f' and 'git rebase'. Also, would
>  patchwork help or hurt us here?

Patchwork is nice, it helps keeping track of the patch status real well.
But there is always the problem of keeping the patchwork up-to-date when
the status of patch changes, esp. if one is offline (or maybe I didn't
look hard enough).

> I think Boris and I have been sort of
>  using it, but it's still got a pretty good backlog (partly real --
>  i.e., the cause for this thread; and partly artificial, due to
>  accounting).
> 
>  What to do about mtd-utils.git? That's been languishing a bit, and it
>  has no release schedule. Maybe we want a plan for that too.
> 
> BTW, will anybody be at Linux Plumbers? I plan to be there in a few
> weeks. And something tells me dwmw2 will be there.
> 
> Brian
> 


-- 
Best regards,
Marek Vasut