Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758025AbcCaWLF (ORCPT ); Thu, 31 Mar 2016 18:11:05 -0400 Received: from mail-ig0-f169.google.com ([209.85.213.169]:35015 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757251AbcCaWLD (ORCPT ); Thu, 31 Mar 2016 18:11:03 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 31 Mar 2016 17:11:01 -0500 X-Google-Sender-Auth: kT0odgekdW7Z1LZuFzebLi-x57Q Message-ID: Subject: Re: [git pull] orangefs bugfixes for rc2 From: Linus Torvalds To: Mike Marshall Cc: Martin Brandenburg , Al Viro , Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1511 Lines: 33 On Thu, Mar 31, 2016 at 4:06 PM, 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... No, for stuff that is entirely internal to a filesystem, the filesystem maintainers should preferably strive to be as independent of all other trees as possible. That means that the base you use should generally be either your own previous top-of-tree (ie without any back-merges from me or other trees at all: so your branch only contains your own work), or if it ends up being more convenient some "well-defined" general release (ie a major release like 4.5, or a later rc like rc4+ that is starting to be considered reasonably stable). For bug-fix pulls, the best base tends to be your own tree that you asked me to pull during the merge window, while then "new development for the next version" might be some known base. Of course, since orangefs just got merged, you can't use 4.5 as a base, but then going forward when you start doing development that you expect to be merged for 4.7, you might want to use 4.6 as a base for that. Right now, using rc1 as a base for fixes would also be reasonable, exactly because you can't use any older release. But in general it's best to try to have better starting points than rc1 (or worse yet, some "random daily point from Linus") which may have undiscovered bugs etc. Linus