Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757666AbcCaW7M (ORCPT ); Thu, 31 Mar 2016 18:59:12 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:58592 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbcCaW7K (ORCPT ); Thu, 31 Mar 2016 18:59:10 -0400 Date: Thu, 31 Mar 2016 23:59:07 +0100 From: Al Viro To: Mike Marshall Cc: Linus Torvalds , Martin Brandenburg , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [git pull] orangefs bugfixes for rc2 Message-ID: <20160331225907.GZ17997@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1805 Lines: 33 On Thu, Mar 31, 2016 at 05:06:17PM -0400, Mike Marshall wrote: > sorry to follow up my own post... perhaps we should > point our pull requests at Al and base them on one > of Al's trees? I'm sure all this should be easy, we're > just clumsy 'cause we're new... Only in cases when you depend on something in my tree. And even then it would be better to discuss the situation so I could put the stuff you really need into a never-modified branch, so that both your tree and mine would contain a merge from it. It varies for different subsystems - e.g. all networking stuff tends to go through the davem's tree; he pulls from submaintainers and feeds the results to Linus. I've no idea how he survives that kind of load and I would certainly prefer to avoid the same role for vfs and filesystems. IMO it's a logistical nightmare; Dave somehow manages to cope with that, but I've no idea how to do that. I would very much prefer to have the inter-tree dependencies minimized, as far as vfs and filesystems are concerned. By default I reorder the stuff in vfs.git as I see fit; if something is needed for another tree, I prefer to add a separate (and usually short) branch with just the required stuff and a promise to never rebase/reorder/etc. AFAICS, nothing in this pull request depends on anything outside of what went into mainline just before -rc1, so I would probably just based that branch at 4599649 and added fixes on top of that. No need to backmerge unless you need something that went into mainline in the meanwhile (and backmerge in that case would better be limited to what you need - e.g. "we need the stuff pulled into mainline from at , so we merge that branch"). Or just base it off -rc1 - that'll give you everything that went into mainline in given merge window...