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

From: James Hogan
Date: Thu Dec 07 2017 - 06:07:14 EST


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.

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

Attachment: signature.asc
Description: Digital signature