linux-kernel - Re: [PATCH 0/1] About MIPS/Loongson maintainance

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]

Date:   Thu, 07 Dec 2017 21:10:10 +0800
From:   Jiaxun Yang <jiaxun.yang@...goat.com>
To:     James Hogan <james.hogan@...s.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Huacai Chen <chenhc@...ote.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Rui Wang <wangr@...ote.com>, Binbin Zhou <zhoubb@...ote.com>,
        Ce Sun <sunc@...ote.com>, Yao Wang <wangyao@...ote.com>,
        Liangliang Huang <huangll@...ote.com>,
        Fuxin Zhang <zhangfx@...ote.com>,
        Zhangjin Wu <wuzhangjin@...il.com>, r@....cc,
        zhoubb.aaron@...il.com, huanglllzu@....com, 513434146@...com,
        1393699660@...com, linux-mips@...ux-mips.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] About MIPS/Loongson maintainance

On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
> On Thu, Dec 07, 2017 at 07:57:59AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> > > Hi, Linus, Stephen, Greg, Ralf and James,
> > > 
> > > We are kernel developers from Lemote Inc. and Loongson community.
> > > We
> > > have already made some contributions in Linux kernel, but we hope
> > > we
> > > can do more works.
> > > 
> > > Of course Loongson is a sub-arch in MIPS, but linux-mips
> > > community is
> > > so inactive (Maybe maintainers are too busy?) that too many
> > > patches (
> > > Not only for Loongson, but also for other sub-archs) were delayed
> > > for
> > > a long time. So we are seeking a more efficient way to make
> > > Loongson
> > > patches be merged in upstream.
> > > 
> > > Now we have a github organization for collaboration:
> > > https://github.com/linux-loongson/linux-loongson.git
> > 
> > Ick, why not get a kernel.org account for your git tree?
> > 
> > > We don't want to replace linux-mips, we just want to find a way
> > > to co-
> > > operate with linux-mips. So we will still use the maillist and
> > > patchwork
> > > of linux-mips, but we hope we can send pull requests from our
> > > github to
> > > linux-next and linux-mainline by ourselves (if there is no
> > > objections
> > > to our patches from linux-mips community).
> > 
> > What does the mips maintainers think about this?
> > 
> > Odds are a linux-next tree is fine, but they probably want to merge
> > the
> > trees into their larger mips one for the pulls to Linus, much like
> > the
> > arm-core tree works, right?
> 
> I'm not officially a MIPS maintainer but I have donned the hat
> unofficially a few times lately, so FWIW I think the Loongson stuff
> should go through the MIPS tree, since it so often touches core
> architecture code.
Yes we are always touching architecture code. For that part, we'll
still submit our patches to linux-mips tree. But we're also maintaining
many platform code under /arch/mips/loongson64 and also platform
drivers such as hwmon, cpufreq and YeeLoong Laptop driver I'm trying to
submit recently. For that part, make a pull request might be more
efficient than apply patches to linux-mips for many times. Just as what
arm architecture did.

We would like to reduce Ralf's work load. Not bypassing him.

> Clearly there have been some issues getting MIPS stuff applied
> recently,
> but I think the right approach long-term is to try and improve things
> there rather than bypass the MIPS tree altogether.
> 
> I believe assigning a co-maintainer would help spread Ralf's load,
> even
> if that primarily means helping review patches (something we can all
> help with tbh), and being able to ack patches which touch MIPS but
> need
> to go through other subsystem trees (e.g. I know David Daney was
> waiting
> on acks for the MIPS portions of the Octeon III ethernet driver
> series).
I agree with that. Ralf really need help.
> I'm willing to take on that role if Ralf is okay with it. I'm already
> trying to keep track of fixes and spend more time reviewing patches
> on
> the list, but the more who can help out the better.
> 
> The question of who applies patches can't be avoided though. It would
> clearly suck to have all the review in the world but still end up
> with
> the co-maintainer having to take the reigns at the last minute to get
> those important fixes in, and then have no time to apply anything
> substantial for the merge window.
> 
> Cheers
> James
-- 
Jiaxun Yang