Received: by 2002:a9a:4c47:0:b029:116:c383:538 with SMTP id u7csp950131lko; Tue, 13 Jul 2021 13:41:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwF9kKjHE22IRubS9WqV0qT9KPoXA8Gw2Y+SSfamTfQJfd2YWTJuCTKBMhBs9uRqD72aqft X-Received: by 2002:a17:906:27da:: with SMTP id k26mr7933354ejc.267.1626208886471; Tue, 13 Jul 2021 13:41:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626208886; cv=none; d=google.com; s=arc-20160816; b=XlUN2nHt7frCt7yakeQqDr+EaS2pogjzdRmblotVBWiefMsVgVn4uGTNbMqoSpUu19 lnTKl5bQqRW/pTkO0ViGHHorWnwJk8jMuc1ZQYK3xP+pBtz9ARHDVmxDw7mwT1xblJeg J03NfSedRkBZcNhE/zTnXPsisrDeRd+sSq+Nn/BBmL2N6gYWknyJ3R+zyj3exjpjKNGI zf42ZIme9STHLEL8lu+PC3lIu53tcuZV+Jse/Drw55EgvH4GW0SMs+qoVtpX2H/9crOG RY/3qGBIZ4YdIX01AyPzH6S0Kn9ne6RDyl/k3B6R7uS6G5Ay9D2X512+bZqcCNR891sN gY7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=WWSb7M+5Se1LMMbds9gcPZqIXIOZEKV8nhXifZ4cRoE=; b=B8BIspcY4Fs4wgYDTnV/mT3I2Y/IEzhGPx+bL9QDV6i1SbXIQlQLvdx4MumPJf3jIg yKtlBCY2A+eSl3dghU26LvS5JA4zc9sUbfJPB+CGvmYpaTVqVQqu9dc5n0VvYEyA5H55 XtSam8d9NZQD73sbSHlC5tcmMBTsGz0jDwcDrGcebtyjjAuPIQIPFbqvPTnYICS0mWlF wLmrcGbJQWZGdTTznp1t5uzXg8OJXC5arls33qMNH6C2jKCopdKpHFRv4ZzyH7FCtxjj kOOf/KERgGTA2Kc4fDmNFEI0ybeWOerShS3pwIWgK21bg9mlfl9xykU7JwuLBEGUPJ+Q nkSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p25si21037281ejb.86.2021.07.13.13.41.02; Tue, 13 Jul 2021 13:41:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234971AbhGMUmr (ORCPT + 99 others); Tue, 13 Jul 2021 16:42:47 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:33280 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229944AbhGMUmr (ORCPT ); Tue, 13 Jul 2021 16:42:47 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3On6-000NOk-R0; Tue, 13 Jul 2021 20:14:04 +0000 Date: Tue, 13 Jul 2021 20:14:04 +0000 From: Al Viro To: Linus Torvalds Cc: Hans de Goede , linux-fsdevel , LKML Subject: Re: [GIT PULL] vboxsf fixes for 5.14-1 Message-ID: References: <30c7ec73-4ad5-3c4e-4745-061eb22f2c8a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 13, 2021 at 12:15:13PM -0700, Linus Torvalds wrote: > On Tue, Jul 13, 2021 at 3:45 AM Hans de Goede wrote: > > > > Linus, sorry for sending this directly through you, instead of going > > through some other tree, but trying to get this upstream through the > > linux-fsdevel list / patch-review simply is not working. > > Well, the filesystem maintainer sending their patches to me as a pull > request is actually the norm rather than the exception when it comes > to filesystems. > > It's a bit different for drivers, but that's because while we have > multiple filesystems, we have multiple _thousand_ drivers, so on the > driver side I really don't want individual driver maintainers to all > send me their individual pull requests - that just wouldn't scale. > > So for individual drivers, we have subsystem maintainers, but for > individual filesystems we generally don't. > > (When something then touches the *common* vfs code, that's a different > thing - but something like this vboxsf thing this pull request looks > normal to me). To elaborate a bit - there's one case when I want it to go through vfs.git, and that's when there's an interference between something going on in vfs.git and the work done in filesystem. Other than that, I'm perfectly fine with maintainer sending pull request directly to Linus (provided that I hadn't spotted something obviously wrong in the series, of course, but that's not "I want it to go through vfs.git" - that's "I don't want it in mainline until such and such bug is resolved").