Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752667Ab3IJWfH (ORCPT ); Tue, 10 Sep 2013 18:35:07 -0400 Received: from mail-ve0-f177.google.com ([209.85.128.177]:56689 "EHLO mail-ve0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256Ab3IJWfG (ORCPT ); Tue, 10 Sep 2013 18:35:06 -0400 MIME-Version: 1.0 In-Reply-To: <20130910152753.662599171456233c5f91edb4@linux-foundation.org> References: <20130910143807.4c32d548e08d2184061f52cb@canb.auug.org.au> <20130910152753.662599171456233c5f91edb4@linux-foundation.org> Date: Tue, 10 Sep 2013 15:35:04 -0700 X-Google-Sender-Auth: 7TiSwiDrWYVvnvSL8GADtlaUzaY Message-ID: Subject: Re: linux-next: manual merge of the akpm tree with Linus' tree From: Linus Torvalds To: Andrew Morton Cc: Stephen Rothwell , linux-next , Linux Kernel Mailing List , Dave Chinner , Al Viro 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: 1653 Lines: 38 On Tue, Sep 10, 2013 at 3:27 PM, Andrew Morton wrote: > > This is rather a fiasco. "vfs: reorganize dput() memory accesses" made > rather a mess of a 46 patch series which has been under development and > test for two cycles so far. Andrew, *please* don't do the insane rebasing you keep on doing. Nobody else does that, and it adds more work for you, and makes your patch bombs be untimely. And I'll be honest, I don't care about the "more work for you" part, since I don't really see it, but I do care about the "untimely" part. That's the one that affects me. For example, I'm traveling starting Friday, so I'll close the merge window on the road (linuxCon US next week, a weekend of diving before that). It would be much nicer if I have almost nothing pending before I leave. And quite frankly, there is absolutely nothing that touches fs/dcache.c that should be in your tree anyway, as far as I can tell. But seriously - don't do the constant rebasing. I tell the git people that, because I hate how it actually dilutes the value of any testing they did. The fact that you rebase to the day you send the patches is actually taking *away* value from what you do, and it adds a lot of work for you. So I'd (once again) suggest you base your pile of patches on the previous stable kernel, and that linux-next take it *first* rather than take it last. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/