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: <20161018214153.69c95a06@bbrezillon>
Date:   Tue, 18 Oct 2016 21:41:53 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Marek Vasut <marex@...x.de>
Cc:     Brian Norris <computersforpeace@...il.com>,
        Richard Weinberger <richard@....at>,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        nicolas.ferre@...el.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 Tue, 18 Oct 2016 21:31:06 +0200
Marek Vasut <marex@...x.de> wrote:

> 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 use git notes + a pre-push hook to help mark a patch as 'Accepted' in
patchwork, but still, it does not automate moving patches to the
'Superseeded' state (which IMO should be directly handled in patchwork)
and those who are rejected. This is why the backlog tend to grow until
I decide to do some cleanup.

We also have all those patches which are over 1 year old, but that we
keep just in case someone wants to revive them.

Anyway, I think patchwork is very useful if it's well maintained, so
maybe we should cleanup things after each release.

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