From owner-svn-src-all@freebsd.org Thu Mar 21 03:17:36 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8F1C154A920; Thu, 21 Mar 2019 03:17:35 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D1B369C27; Thu, 21 Mar 2019 03:17:35 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.2] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id 862EE136EA; Thu, 21 Mar 2019 03:17:34 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: svn commit: r345350 - in head: . lib/libjail sbin/mount_fusefs sys/conf sys/fs/fuse sys/modules sys/modules/fuse sys/modules/fusefs To: rgrimes@freebsd.org, Alan Somers Cc: src-committers , svn-src-all , svn-src-head References: <201903210313.x2L3DB25058545@gndrsh.dnsmgr.net> From: Pedro Giffuni Organization: FreeBSD Message-ID: <4813d987-5803-d466-442d-3b6098fcc586@FreeBSD.org> Date: Wed, 20 Mar 2019 22:17:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <201903210313.x2L3DB25058545@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 5D1B369C27 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 03:17:36 -0000 On 20/03/2019 22:13, Rodney W. Grimes wrote: >> On Wed, Mar 20, 2019 at 4:01 PM Rodney W. Grimes >> wrote: >>>> Author: asomers >>>> Date: Wed Mar 20 21:48:43 2019 >>>> New Revision: 345350 >>>> URL: https://svnweb.freebsd.org/changeset/base/345350 >>>> >>>> Log: >>>> Rename fuse(4) to fusefs(4) >>>> >>>> This makes it more consistent with other filesystems, which all end in "fs", >>>> and more consistent with its mount helper, which is already named >>>> "mount_fusefs". >>>> >>>> Reviewed by: cem, rgrimes >>> I did not review this code, I made a single comment that >>> it should be discussed on an applicable mail list (arch@) >>> which you did do, and I thank you for that. >>> >>> I would of eventually objected to the "do not rename the source", >>> as that is one of the sighted reasons we use svn, is it is near >>> costless to do moves, and this just trades one missmatch for >>> another, which in my book is a near nop. >>> >>> Reviews are still not being allowed enough world rotates >>> before committing. I am presently abroad, with poor net, >>> and busy. >> Sorry, I didn't realize you weren't done. > What is the current acceptable "wait" time when asking a public > list for a review/response to some operation? > >> But the other great thing >> about SVN is that we can do stuff, and then do more stuff. Would you >> like for me to rename the source files as well? I could do that. > I suspect now that the code is committed, and that others have > responded, maybe a proper amount of discussion shall occur and > this decision made by more than 3 people. > >> The >> one thing that I won't agree to do is to rename fuse_kernel.h => >> fusefs_kernel.h, because that file comes verbatim from upstream and we >> should keep the original name to make it easy to find(1). > If this code comes from upstream we should try to maintain the > same file names, in as many cases as we can. Did the commit > made increase or decrease that miss match? Is there only one > file from upstream? > > Does it make any since to set this code up as a vendor branch? > No: fuse_kernel.h is the only file with a real upstream. Pedro.