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
signature.asc
Description: Digital signature