From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51B99C433E0 for ; Mon, 11 Jan 2021 16:09:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 044B322A84 for ; Mon, 11 Jan 2021 16:09:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388809AbhAKQJJ (ORCPT ); Mon, 11 Jan 2021 11:09:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:40528 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387962AbhAKQJI (ORCPT ); Mon, 11 Jan 2021 11:09:08 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 89CB021D7F; Mon, 11 Jan 2021 16:08:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1610381308; bh=5fZnpwgj10vPRw+LiuHoD3+pb12cQ9s/sMY2kXPo4is=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UuDK2KSpROlsOnFjMtQU+xGSNBANbyERFpXjd4JfEirPRtofCeO5W7gzY9Un3exBB wjOozse6h6bmYcV9Ue8vCxqPRWJoNCXaLU52VqIp0BwVnpUktgi33cH/0L56pPZmpQ znrFdVEzKaefhaL3Lu6vIMX1//hdei748FmXqRV4= Date: Mon, 11 Jan 2021 17:09:38 +0100 From: Greg KH To: Tom Rix Cc: Moritz Fischer , "linux-fpga@vger.kernel.org" , linux-kernel@vger.kernel.org, moritzf@google.com, Rikard Falkeborn , Zheng Yongjun , Russ Weight , "Gerlach, Matthew" , Sonal Santan , Xu Yilun , Richard Gong Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12 Message-ID: References: <20210107043714.991646-1-mdf@kernel.org> <80b29715-aa0a-b2ac-03af-904fc8f8be98@redhat.com> <95af46d6-d123-f610-2f21-6d6de6f248e9@redhat.com> <9bc01a73-726f-a979-1246-6ea048961670@redhat.com> <7923d9dc-c503-5318-6e4f-931f8c13c1be@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7923d9dc-c503-5318-6e4f-931f8c13c1be@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-fpga@vger.kernel.org On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote: > > On 1/11/21 6:54 AM, Greg KH wrote: > > On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote: > >> On 1/10/21 10:57 PM, Greg KH wrote: > >>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote: > >>>> On 1/10/21 9:05 AM, Moritz Fischer wrote: > >>>>> Tom, > >>>>> > >>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote: > >>>>>> On 1/7/21 8:09 AM, Tom Rix wrote: > >>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote: > >>>>>>>> This is a resend of the previous (unfortunately late) patchset of > >>>>>>>> changes for FPGA DFL. > >>>>>>> Is there something I can do to help ? > >>>>>>> > >>>>>>> I am paid to look after linux-fpga, so i have plenty of time. > >>>>>>> > >>>>>>> Some ideas of what i am doing now privately i can do publicly. > >>>>>>> > >>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state. > >>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches > >>>>> that require the changes that went into Greg's branch I can merge. > >>>> I mean the window between when we have staged patches and when they go into Greg's branch. > >>>> > >>>> We don't have any now, maybe those two trival ones. > >>>> > >>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge. > >>> Ick, no! NEVER rebase a public branch. Why does it matter the speed of > >>> my branch vs. anyone elses? Git handles merges very well. > >>> > >>> Just like Linus's branches move much faster than mine, and I don't > >>> rebase my branches, you shouldn't rebase yours. > >>> > >>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no > >>> git pulls, so why does it matter at all for any of this? > >>> > >>> What is the problem you are trying to solve here? > >> This 5.12 fpga patchset not making it into 5.11. > > Ok, but isn't it the responsibility of the submitter to make sure they > > apply properly when sending them out? > > > >> At some point before the 5.11 window, I tried it on next and it failed to merge. > >> > >> This points to needing some c/i so it does not happen again. > > "again"? Merges and the like are a totally normal thing and happen all > > the time, I still fail to understand what you are trying to "solve" for > > here... > > What can I do to help make your merges as easy as possible ? I have not had any problems with merges, I've only had "problems" rejecting patches for their content. Try helping out with patch reviews if you want, finding and fixing things before I review them is usually a good idea :) > Does the patchwork infra Moritz was speaking of earlier need fixing help? No idea, I don't use it. > Any other things ? What problems are you trying to solve here? What's wrong with how this subsystem is working that you are feeling needs to be addressed? confused, greg k-h